![]() 膨大な数の処理命令のリアルタイム処理に関する改良
专利摘要:
極めて多数の処理命令を処理セッション中にリアルタイムに処理及び操作するシステム(150)が開示される。各処理命令は2つの異なるエンティティ(14,16)に関するリソースアカウントデータファイル(30)及びこれらのファイル(30)間で交換されるリソースの量(額)及びタイプを指定するものである。本システムは、前記処理命令に関連するリファレンスデータを取得するプリローダ(152)を備え、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記プリローダはマスタデータベースから複数のそれぞれの受信処理命令に対するリファレンスデータを並列に読み出すように構成され、更に複数の前記処理命令をそれらのそれぞれプリロードされたリファレンスデータと一緒にキューイングするエンリッチ命令キュー(166)と、受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な処理命令に対して更新コマンドを発生するように構成された実行エンジン(154)と、前記実行エンジン(154)からの前記更新コマンドに応答して、前記マスタデータベース(24)を各実行可能な命令の結果で更新する複数のアップデータ(158)とを備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されている。 公开号:JP2011513825A 申请号:JP2010548197 申请日:2009-02-27 公开日:2011-04-28 发明作者:ぺティット アンリ;デロゲ クリスティン;フランソワ;コリン ジャン;マーシャル ニコラス 申请人:ユーロクリア エスエー エヌヴィーEuroclear Sa/Nv; IPC主号:G06F12-00
专利说明:
[0001] 本発明は、膨大な数の処理命令のリアルタイム処理の改良に関するものである。より詳しくは、本発明は、毎秒何百もの命令の処理を最適化するように特別に設計されたコンピュータ処理アーキテクチャに関するものであるが、これに限定されない。] 背景技術 [0002] 膨大な数の処理命令をリアルタイムに処理する問題に取り組む様々なアプローチが存在している。これらのアプローチのすべては膨大な数の命令の処理に成功しており、この成功の大半はより高速でよりパワフルな演算を使用する処理システムに依存している。しかし、このようなアプローチに基づくアーキテクチャは、このようなシステムの最大可能なスループットを制限するなど、いろいろの点で制限を受ける。] [0003] このような技術にはいくつかの応用分野があり、例えばマスデータ通信システム及びデータ処理システムなどがある。このようなデータ処理システムの一つの非限定的な例は取引決済システムであり、このシステムでは異なるパーティ間の契約(agreement)を表すデータ命令メッセージを、当該契約の実際の決済又は実行を達成するために実行することができる。その一例が以下に詳細に記載されるこのような契約においては、信頼できる決済エンティティコンピュータへの命令(又はコマンド)は、決済エンティティコンピュータにより決定される条件(規則)がこれらの命令の実行を許す場合にのみ処理され得る。従って、プロセスの第1の部分として、リソースに対する電子データファイルの現在状態について検査を行う必要があり、これは和解契約の主部である。これらの検査は、命令の実行が電子データアカウントファイルに与える影響を許容し得るかどうかを決定する。] [0004] プロセスの第2の部分において、命令は、実行が許可される(「コミット」という)か、実行が拒否される(「ロールバック」という)かのいずれかである。もっと具体的にいうと、この非限定的例では、命令を電子データアカウントファイルに許容し得ないポジションを生じることなく実行できるかどうかを決定するために、両パーティのリソースアカウントファイルのポジションが決済エンティティコンピュータにより評価される。条件が適合する場合には、データレコード内に含まれる命令(コマンド)が実行され、次いでリソースアカウントの現在のポジションを格納するデータファイルが更新される(コミット)。条件が適合しない場合には、命令はこの時点で実行されずに電子データアカウントファイルはそのまま維持される。また、第1段階が、電子データアカウントファイル上の結果ポジションが許容し得ないことを示す場合には、すべてのアカウントをデフォルトとして更新し、更新を無効にすることもできる(ロールバック)。これは、高いスループットシステムに対して好適なオプションである。条件が失敗した命令に対して変化したら、ロールバックされたデータ命令を再利用し、関連するコマンドをその後の段階で再試行することができる。更に、そのすべてを契約に関係するパーティのコンピュータに、多くの場合リアルタイムに、報告する必要がある。] [0005] このようなデータ処理の実行の特性の一つは、これまで、提案されている解決方法のスケーラビリティを制限しており、それはこれらの命令を実行するために評価する必要がある異なるリソースの数が多くの場合命令の増加する数とともに増加しなくなることにある。これは、多くの場合、命令の数の増加とともに命令の実行が所定数のリソースに集中するためである。この集中は、リソースアカウントファイルの値に影響を与える各命令が、次の命令の前に、当該アカウントを処理できることを指定する値を更新する必要があるために問題になる。典型的には、これは、プロセスが所定のリソースアカウントファイルの値の検査及び更新である間に、所定のアカウントファイルの一時的独占性(ロッキング)を取る特定の命令によって達成される。次の命令を処理できる前の所要の更新は、これらの増加した数の命令を処理できる最大速度への直接影響を有する。これは、多くの異なるタイプの命令に共通のエンティティのリソースにとって厳しい問題となる。これは、特に、命令の50%がリソースアカウントの5%のみを更新する場合(高い集中状態とみなせる)に、特に厳しい問題となる。] [0006] この非限定的な例は、実行すべき命令に対してファンドが有効であるかどうかを確かめるためにエンティティに対するキャッシュアカウントを格納するデータファイルを検査する必要があるときに、理解することができる。各命令に対するこのリソースのアカウントの検査は、前命令がその命令の実行の結果としてキャッシュアカウントポジションを更新した後に実行する必要がある。それゆえこれらのプロセスはシーケンシャルにする必要があり、さもなければ当該アカウントのバランス(残高)を変化させるかもしれない一つの命令の実行の作用が当該アカウントへのアクセスを必要とする次の命令を無効にし得る。従来のアーキテクチャ(以下に記載する)の最大処理速度はすべてこの問題により制限される。] [0007] 同時処理アーキテクチャが使用されている従来のシステムに生じる別の問題は「デッドロック」である。この問題を含む状態は、2つの同時の命令が同じ2つのアカウントにアクセスする場合に生じ、一方の命令が一方のリソースアカウントをロックし、他方の命令が他方のリソースアカウントをロックする。これは、各命令に対して、その命令を実行すべく、検査のために他方のアカウントにアクセスすることを阻止する。両命令が待ち状態になり、両命令が命令の処理のためにコミット(実行)操作を実行するのを阻止する。一方の命令のロールバックは他方の命令の処理を開放し、常に可能であるが、この解決方法は命令処理のスループットを大幅に減少する。] [0008] 電子アカウントファイルを検査し更新する基本プロセスは単一の命令に対してはあまり重要でないように思われるが、1日につき何百万ものこのような命令の処理はこの解決方法を重要なものとする。決済エンティティにより使用される如何なるシステムの目的も、リアルタイムに可能な最高のスループットを達成することにある。いかなる解決方法のスケーラビリティも、任意の処理ステップの如何なる小さな時間の節約も大量の命令処理のために多数倍に増大されるので、極めて重要である。] [0009] このような決済プロシージャを実施する多くの従来のシステムが開発され、このようなシステムの典型的な例が図1〜図5を参照して以下に記載される。] 図1 図10 図11 図12 図2 図3 図4 図5-1 図5-2 図6 [0010] 図1を参照すると、1日につき何百万もの命令データメッセージを取り扱うように構成された従来の汎用中央リソース管理システム10が示されている。システム10は、専用リース通信ライン又は他のタイプのセキュア通信チャネルとし得る種々の通信チャネル12に結合される。システム10はこれらのチャネルを介して多くの異なるパーティのサーバに接続される。この実施例では、説明を容易とするために、システム10はパーティAのサーバ14及びパーティBのサーバ16に接続される。パーティAのサーバ14及びパーティBのサーバ16はそれぞれのデータベース18,20のレコードにアクセスすることができ、各レコードは別のパーティとの契約を記述する。] 図1 [0011] 中央リソース管理システム10は、典型的には命令実行サーバ22を備え、該サーバはすべてのパーティ(即ち本例ではA及びB)のリソースアカウントを表すデータレコードを含むマスタリソースデータベース24にアクセスすることができる。] [0012] 図2を参照すると、各パーティに対するマスタリソースデータベースの構造の概略的表現が示されている。データベース24は、各パーティに対する複数の異なるタイプのリソースアカウントファイル30と、当該パーティに対する集計(aggregated)リソース値のインジケータ32とを備える。この特定の実施例では、命令データメッセージの各々は、これらのアカウントファイル30にコマンド又は命令を実行するように指示し、典型的には一つのパーティのアカウントから別のパーティのアカウントへリソースを移動させ、これに応じて集計リソース値インジケータ32を更新するように指示する。アカウントはパーティ14,16の実際のリソースを表すデータファイルである。リソースはパーティの任意のリソースとすることができる。本例では、それらのリソースはパーティが所有するものであって該パーティが取引したいものである。] 図2 [0013] 次に図3を参照すると、命令データメッセージ40の一般構造又はフォーマットが示されている。命令データメッセージ40は、本質的に、命令を実行するために必要な6個の基本フィールドを有する。命令データメッセージ40は命令に対するパーティを識別するためのパーティIDフィールド42を有する。本例では、命令データメッセージ40はパーティA及びパーティBを識別することができる。この命令メッセージ40を実行すべき日時を規定するために実行日フィールド44が付与される。残りの4つのフィールドは命令の主部であり、リソースの詳細を特定する。第1リソースタイプフィールド46及び対応する第1リソース数量フィールド48は、第1パーティ(例えば、パーティA)のリソース及び命令に含まれる当該リソースの数量(額)を特定するために付与される。第2リソースタイプフィールド50及び対応する第2リソース数量フィールド52は第2パーティ(例えば、パーティB)のリソース及び命令に含まれる当該リソースの数量(額)を特定するために付与される。] 図3 [0014] 2つのパーティ間の各契約に対して、2つの命令データメッセージ40(各パーティに対して一つずつ)が存在する。] [0015] 図4は、図1の従来の命令実行サーバ22のコンポーネントを示す。これらのコンポーネントは、受信した命令データメッセージ40の妥当性を検証するように構成された命令検証器60と、同じ契約に関連する2つの異なる命令データメッセージ40を照合する命令照合器モジュール62とを含む。命令照合器はまた、合致した命令データメッセージ40に対して決済命令を生成する。更に、現在時間を新たに生成された決済命令と関連する時間と比較するためにタイミングモジュール64が設けられる。タイミングモジュール64は、更に、各パーティのリソースアカウントファイルへのアクセスのための時間窓が開いているか閉じているかを決定することができる。決済命令を今後の実行のために格納するために命令データベース66も設けられる。命令実行サーバ22は、更に、情報メッセージを関連するパーティへ通信する報告モジュール68を備える。最後に、命令実行サーバの心臓部として、命令検査、実行及び更新エンジン70が設けられる。報告モジュール68は命令検証器60、命令照合器62及び命令検査、実行及び更新エンジン70に結合される。命令が処理される手順は命令検査、実行及び更新エンジン70の特定のデータ処理アーキテクチャにより決まり、これは(以下に記載するように)様々な従来の装置の間で相違する。] 図1 図4 [0016] 次に、命令実行サーバ22の動作が図5のフローチャートについて説明される。ポジショニングエンジン70において命令(決済命令)を実行することにより命令データメッセージ40を受信し、検証し、照合し、更新し、更新の結果を報告するステップが以下に詳細に説明される。もっと正確にいうと、従来の命令実行サーバ22の一般的な操作78はステップ80で開始し、サーバ22は通信チャネル12に接続され、命令データメッセージ40の受信が可能である。次にパーティAがステップ82においてパーティBとの契約を記述する命令データメッセージ40をサーバ22に送る。同様に、パーティBがステップ84においてパーティAとの契約を記述する命令データメッセージ40をサーバ22に送る。サーバ22において、メッセージ40が受信され、命令検証器60がステップ86において、受信された各命令を検証しようと試みる。この検証がステップ86において失敗すると、この失敗はステップ90において報告モジュール68に通知され、報告メッセージ(図示せず)がステップ90において無効とされた命令データメッセージ40の発信元に送付される。] [0017] 反対に、有効な命令データメッセージ40に対しては、報告モジュール86はステップ92において有効な命令メッセージ40の発信元に、命令データメッセージ40の受信及び検証有効を示す肯定メッセージを返送するように命令する。] [0018] 有効な命令メッセージ40は命令照合器62へ渡され、ステップ94において同じ契約を記述する対応する2つの命令データメッセージ40を照合する試みが行われる。] [0019] 命令照合器62は、ステップ96において、異なるメッセージ40を照合しようと試みる。ステップ96における照合検査が失敗すると、この失敗はステップ98において報告モジュール68に通知され、ステップ98において報告メッセージ(図示せず)が合致しない命令データメッセージ40の発信元に送られ、プロセスはステップ100で終了する。この失敗は従来のシステムの説明を簡単にするために極めて簡単に示されている。しかし、実際には照合の失敗は多くの試みの後、おそらく数日かもしれない設定照合期間の満了後にのみ到達する結論である。] [0020] ステップ96において決定された合致した命令メッセージ40は報告モジュール68に通知され、このモジュールが次いでステップ102において合致した命令データメッセージ対の存在を合致した命令データメッセージの発信元(本例ではパーティA及びパーティB)に報告する。更に、命令照合器62はステップ102において実行日を有する実効命令(決済命令)を生成する。この実行日はステップ104において合致した命令データメッセージ40のいずれか一方の実行フィールドの日時(両方とも同じであるため)から得られる。決済命令の実行日は次にステップ104において現在時間および(タイミングモジュールにより決定される)実行時間窓の有効性と比較される。] [0021] ステップ106で決定される比較の結果が、決済命令は現在実行不可能である場合には、決済命令はステップ108において命令データベース66に格納される。データベース66は定期的に検査され、プロセス78はステップ110において、実行日になるまで待ち、実行時間窓を開く。典型的には、実行時間窓は毎日数時間開くことができる。] [0022] また、ステップ106で決定される比較の結果が、決済命令は今実行可能である場合には、決済命令は格納されない。] [0023] 命令実行サーバ22の一般的な操作78の次の段階は、ステップ112において、決済命令を命令検査、実行及び更新エンジン70(ポジショニングエンジンともいう)に送る。ポジショニングエンジン70は一組の実行規則72と関連する。これらの規則72は、決済命令を実行できるかどうか、つまり、リソースアカウントファイル30及び集計リソース値32に対する決済命令の結果を受諾できるかどうかを決定する。受諾できない条件の一例は、特定のリソースアカウントファイル30又は集計リソース値32がコマンドの実行の結果として所定額より低い値になる場合である。上述した非限定的な取引決済システムの実施例では、リソースアカウントは現金及び担保アカウントとすることができ、集計リソース値はクレジットライン(貸付限度額)とすることができ、この場合リソースは与えられるクレジット(貸付金額)に対する保証として作用するので、リソースの現在値は所定の貸付金額を提供する。] [0024] ポジショニングエンジン70は、ステップ141において、もしコマンドが実行された場合に実行規則72が依然として満足されるかどうか、即ち2つのパーティのリソースアカウントファイル30及び集計リソース値32に対して得られる結果が許容できるかどうかを検査する。] [0025] 実行規則がステップ116において満足されないと決定されると、プロンプトが報告モジュールに送られ、ステップ118において報告モジュールは、失敗した決済命令に対して不成功結果を両パーティ(例えば、本例ではパーティA及びパーティB)に報告するメッセージを生成し送付する。次に、失敗した決済命令はステップ120においてポジショニングエンジン70にとどまり、決済のために後刻/後日に再試行される(ステップ114−126を反復する)。] [0026] 実行規則72がステップ116において満足されると決定されると、決済命令はステップ122で実行される。このとき、ポジショニングエンジン70はステップ124において、リソースアカウントファイル30の現在のポジションを実行された決済命令の結果で更新する。つまり、リソースアカウントファイル30及び集計リソース値32はリソースの移動が行われた後に正しいバランスで更新される。最後に、報告モジュール68がステップ126において、成功決済命令に対して決済の成功結果を両パーティ(例えば、本例ではパーティA及びパーティB)に報告するメッセージを生成し、送付するように命令される。] [0027] 決済命令の成功した実行は、従来の命令実行サーバ22の一般的な操作78を当該単一命令に対して閉じる。しかし、何百万もの命令が毎日処理されているので、プロセス78は多くの異なるパーティのサーバから絶えず受信される他の命令データメッセージ40に対して継続する。] [0028] 以上述べたように、決済命令が処理される手順は命令検査、実行及び更新エンジン70の特定のデータ処理アーキテクチャにより決まり、これは従来の異なるシステムの間で変化する。本質的に、2つの異なるアプローチ、即ちバッチプロセス及び並列入力照合プロセスが存在し、次に両プロセスがそれぞれ図6及び図7を参照して説明される。] 図6 図7 [0029] バッチプロセスは標準のシーケンシャル更新アプローチであり、このアプローチでは実効命令がシーケンシャル処理のために格納され、自動的に連続的に実行される。このプロセス130は図6に概略的に示され、新命令(決済命令)のバッチ(シーケンシャルセット)を含む新命令ファイル132が、すべてのリソースアカウントファイル30の現在のポジション及び任意の集計ポジション32を格納するマスタファイル134と一緒に与えられる。] 図6 [0030] 各決済命令は、図3につき述べたように、契約に関係する2つのパーティ、リソースアカウントファイル30、パーティ間の契約の主部であるリソースの数量及び実行時刻/日を特定する。このタイプの処理アーキテクチャの重要な特徴は、これらの決済命令をそれらが関連するリソースアカウントの順にリストアップする必要があることである。典型的には、各命令に相互参照を助けるシーケンスキーが付与される。] 図3 [0031] マスタファイル134もまた上述のシーケンスキーを用いてリソースデータアカウント30を順にリストアップする。このマスタファイルと入力データファイルとの間の順序の一致はバッチ処理にとって極めて重要である。] [0032] シーケンシャル更新プログラム136は、各契約が対応する命令の決済により実行され得るか同化を決定するために設けられている。処理エンジン(図示せず)で実行されるシーケンシャル更新プログラムは、照合アルゴリズムと呼ばれる標準のアルゴリズムを用いる。上述したように、照合アルゴリズムは、両入力ファイル(現存するマスタポジションファイル134及び新命令ファイル132)が同じ順序のシーケンスキーで格納されていることを要求する。命令ファイル132で使用されるキーは「トランザクション」キーと呼ばれ、現存するマスタファイル134に格納されるキーは「マスタ」キーと呼ばれる。] [0033] シーケンシャル更新プログラム136は両ファイル132,134を両ファイルの終わりまで順に読み取るようにロジックを定義する。シーケンシャル更新プログラムの結果は新マスタファイル138に格納され、このファイルはパーティのすべてのリソースアカウントファイル30及び集計ポジション32の更新されたポジションを保持する。] [0034] シーケンシャル更新プログラム136は、各ファイル132,134の第1の命令又はレコードを読み込むことによって開始する。所定のリソースアカウントファイル30に関連する命令のすべてがシーケンシャルに実行され、リソースアカウントファイル30の値の各変化が照合アルゴリズムを実行する処理エンジンのメモリにおいて更新される。特定のリソースアカウントファイル30に対する更新が完了すると(次の命令に対するトランザクションキーの変化により検知される)、当該リソースアカウントファイル30に対して得られた値が任意の更新された集計ポジション32と一緒に新マスタファイル138に書き込まれる。このプロセスは異なるリソースアカウントファイル30ごとに、トランザクションファイル132の終わりに到達するまで、繰り返される。] [0035] 一つの命令を実行するために多数のリソースアカウントを更新する必要がある場合、もっと洗練されたアプローチが使用される。多数のアカウントの更新を処理するために、更新は複数の段階に分解される。この解決法は、リソースアカウント値のデビットを最初のランでのみ実行し、デビットが成功した場合命令をリソースアカウントのクレジットの順に、クレジットを対応するリソースアカウントに供給する前に、報告する。リソースアカウントのクレジット支払いが遅れたために失敗した命令によって問題が生じるが、これは多数のランを行うことで解決される。] [0036] シーケンシャル更新プログラム136は、典型的には、次のケースを処理するようにロジックを定義する。 トランザクションキー=マスタキー→現在の命令をリソースアカウントファイルの現在のマスタデータレコードに適用する →現在のリソースアカウントの新ポジションを更新されたマルチレコードとしてメモリに格納する →次の命令を読み込む トランザクションキー>マスタキー→更新されたマスタデータレコードを新マスタファイル138に書き込む。 →マスタデータレコード(有効であれば)を回復させる、または、次のマスタデータレコードに対してマスタファイルを読み込む トランザクションキー<マスタキー→現在のマスタレコードを格納する →デフォルトマスタレコードを生成する →トランザクションファイルから次の命令を読み込む、または、 →対応するマスタファイル情報が存在しない、即ちアカウントリソースファイル30がマスタファイル134に見つからないために命令を除去する →次の命令を読み込む] [0037] これが行われると、次の命令レコードがトランザクションファイル132から読み込まれ、トランザクションキーが現在のマスタキーより大きくなるまで同じプロセスが繰り返される。] [0038] このアルゴリズムでは、メモリ内の単一のプロセスが多数の更新を新マスタファイル138に収集するので、命令の高速処理を提供すること明らかである。制限は、プロセスを実行する前に、すべての命令をグループ化し、ソーティングする(バッチ)必要があることである。更に、命令の実行を確認する第1の応答メッセージをパーティに返送する前にすべての命令が処理されなければならない。更に、バッチプロセスにおいては、照合アルゴリズムを実行しながらデータを他のプロセスのために使用することはできない。データへのリアルタイムアクセスを提供するために、データベースの更新が必要とされる。これらのデータベースの更新は、直接実行すると、プロセスの総合スループットを大きく損なう。実行後に追加のステップで実行される場合(例えばDB2ロードユティリティ)、この時間中データへのすべてのアクセスが阻止される不利がある。この結果として、バッチ処理は実行中極めて効率的であるが、実行前にグループ化及びソーティングを必要とするためにリアルタイムに実行することはできない。] [0039] 別の代替アプローチ、即ち上述した並列入力照合アプローチが図7に示されている。このアプローチにおいては、命令照合器62により生成される決済命令は複数の個々の命令操作コンピュータ又はプロセス140,142により操作される。シーケンシャルファイル操作プロセス144は命令データベース66に格納されている命令のバッチを操作することができる。各プロセス140,142,144は直接更新プログラム146の自己バージョンを有し、該プログラムは現在のリソースアカウント30及び集計リソース値32の値を読み込み、マスタデータベース24内のパーティのリソースアカウントに対する直接更新命令を生成する。単一命令実行マネージャ148は、プロセス140,142,144からの受信命令によってデータベース24の更新について最終判断を行うために設けられている。命令実行マネージャ148は一組の実行規則72(図4参照)を用いて更新命令の実行をコミットするか後の実行のためにロールバックを行う。] 図4 図7 [0040] 命令実行マネージャ148が実行しなければならない実行規則72の一つはロックアウトの問題に対処するものである。前述したように、ロックアウトは、リソースアカウントファイル30へのアクセスが別の更新命令に対して使用されている最中であるために阻止される場合である。実際には、これは、特定のリソースアカウント30を更新する競争が、リソースアカウントファイル30が前更新命令から開放されるまで、即ち前更新が完了するまで待ち状態の挿入によって処理されることを意味する。このようにすると、命令実行マネージャ148は2つの異なる更新命令が同じリソースアカウントファイル30を並列に変更することを阻止する。] [0041] 各プロセス140,142,144は並列にランし、単一プロセスより広い帯域幅を提供し、より大きな潜在的スループットをもたらす。もっと詳しく言うと、更新が多数の異なるリソースアカウントファイル30に分散される場合、並列システムはスケーラブルになる。このような環境の下では、多数の更新プロセス140,142,144を並列にランさせることによってシステムのスループットを増大することができる。しかし、更新が十分に分散されない場合、データ完全性を保証するためのロックアウトプロセスの実行はシステムが到達し得る最大スループットを急速に制限する。この限界に到達すると、使用不能(ロックされた)リソースアカウントファイル30に対する他の更新命令の待ち時間が増大するため、一つ以上の更新プロセスのランは総合スループットを増大しなくなる。] [0042] このアプローチはリアルタイム更新のために優れているが、多くの状態の下でスループットの低下を被る。これは、通常、更新は多数の異なるリソースファイル30に分散されないためである。むしろ、多くのアプリケーションにおいては、一般に所定のリソースアカウントが多くの異なる命令により頻繁に使用されている。例えば、取引決済の分野では、一般に命令の50%が利用可能なリソースアカウントファイルの5%に集中している。これらの状況の下では、図7のリアルタイム処理技術は性能不足である。] 図7 [0043] 考慮すべき別の問題は、失敗した命令を再利用する問題である。リソースアカウントが実行規則を満足する所要の値を持たないために特定の瞬時に実行できなかった命令は後刻の別の実行試みのために単に格納される。一時的失敗の各々は命令装置に報告し、いったんリソースアカウント状態が変化すればその命令はまもなく実行できることを指示することができる。] [0044] この従来の再使用プロセスは実行エンジンへの新命令の提出の数を減少させるのに有用である。命令を「ペンティング」として保持することによって、状態の変化時にそれが処理されるチャンスが大きくなる。処理する命令の量を考えると、殆どの再使用命令が最終失敗として報告する必要なしに実行される確率が高くなる。] [0045] しかし、再使用は実行エンジンのスループットが再使用プロセスにより低下される問題をもたらす。特に、並列入力である場合、多数のリソースアカウント移動を記述する命令は、多くの場合、再使用期間(タイムアウトの発生前)内にそれらの実行条件にならないので、失敗する。シーケンシャル入力の場合には、失敗は、失敗した命令を操作するために必要とされる多数のランをもたらすことになり得る。] [0046] これらの問題を克服しようと多くの努力がなされている。また、これらの問題を解決するために多大なお金と資源が費やされている。これらの努力にもかかわらず、命令処理アーキテクチャにおけるスループット対リアルタイム処理の問題はそのままである。] [0047] これらの問題を明らかにするのに役立つ様々な従来の技術が下記の文献に開示されており、これらの文献が公知になってから長い時間たつが実行可能な解決手段は見つかっていない。] [0048] KAl LI ET AL'Multiprocessor Main Memory Transaction Processing" 19881205; 19881205-19881207, 5 December 1988, pages 177-187, XP010280434. GARCIA-MOLINA H ET AL: 'MAINMEMEORYDATABASESYSTEM:AN OVERVIEW<1>IEEE TRANSACTIONS ON KNOWEDGE AND DATA ENGINEERING, IEEE SERVICE CENTRE, LAS ALAMITOS, CA, US, vol. 4, no.6, 1 December 1992, pages 509-516, XP001 167057 ISSN: 1041 -4347. GRAY J ET AL: "Transaction processing: concepts and techniques,PASSAGE' 1 January 1993, TRANSACTION PROCESSING: CONCEPTS AND TECHNIQUES, PAGE(S) 249 - 267, 301 , XP002323530. GRAY J ET AL: "Transaction processing: concepts and techniques' 1 January 1993, TRANSACTION PROCESSING: CONCEPTS AND TECHNIQUES, PAGE(S) 333 - 347, 496, XP002207245.] [0049] 本発明は、上述した問題の少なくともいくつかを克服し、極めて多数の処理命令をリアルタイムに処理及び操作する改善されたシステムを提供しようとするものである。] [0050] 本発明の目的を更に詳細に考察する前に、任意の命令処理アーキテクチャのいくつかの重要な特性を理解することが重要であり、それらを以下に示す。] [0051] 新システムの各々は特定のスループット要件を有する。スループットはシステムの目的を達成するためにシステムが所定の期間内に実行すべき命令の数を表す。スループットは1日、1時間、1分間又は1秒間当たりの命令処理数で表される。スループットは、100命令/秒より大きいとき、「高スループット」と規定される。] [0052] 処理アーキテクチャを命令プロセッサのシングルインスタンスで実現するシステムにおいては、プロセッサは所要のスループットを達成できる必要がある。しかし、シングルプロセッサでこれを達成できない場合、目的を達成できるように複数インスタンスのプロセッサで命令を並列に処理する必要がある。後者の場合には、総合スループットは各インスタンスにより達成されるスループットの和である。命令実行プロセスが複数の順次のステップからなる場合、総合命令実行プロセスのスループットは最も弱い(最も遅い)ステップ(例えばボトルネック)のスループットにより決まる。] [0053] 新システムの応答時間は、第3パーティのサーバからの入力命令実行要求の受信と該サーバへの関連する応答の返送との間の経過時間を表す。5秒未満の平均応答時間を有する命令処理システムはリアルタイムシステムと規定することができる。命令プロセッサのシングルインスタンスをランしているとき、応答時間は要求を処理する時間(要求を読み込み、命令を実行する時間)及び応答を送る時間(応答を生成し,それを送る時間)として測定することができる。要求がシステムのスループットより高いレートで到来する場合、要求の待機が起こる。この場合には、要求がキューで費やす時間を該要求に対する総合システム応答時間の一部分とみなす必要がある。命令プロセッサが複数の処理ステップからなる場合、システムの総合応答時間は複数のステップの各々の応答時間の和として計算される。] [0054] 典型的には、各命令処理システムは何百ものパーティで動作し、各パーティに対して局所的に格納された対応するリソースアカウントを有する。各パーティは多数のリソースアカウント(数十及び数百も珍しくない)を持ち得るので、命令が関係するリソースアカウントは多数のリソースアカウントファイルに均等に広がる。しかし、命令処理システムのいくつかの特定のアプリケーションにおいては、要求は、小さな組のリソースアカウントファイルが命令に頻繁に含まれ、それらが高い周波数で更新されることになる。命令処理システムにおける命令の集中により、小さな組のリソースアカウントファイルが処理された命令に含まれる頻度が決まる。50%の命令が5%のリソースアカウントファイルを更新する命令処理システムは高い集中を有すると規定される。] 先行技術 [0055] 上記の特性を前提にすると、本発明の別の特定の目的は、リアルタイム(上で定義済み)に動作し、高いスループット(上で定義済み)を有し、高い集中(上で定義済み)を操作しうる命令処理システムを提供することにある。] [0056] 本発明は、高い命令の集中を処理しうるリアルタイム命令処理システムにおいて極めて高速のスループットを達成しようとする際に、従来のアプローチの制限をある程度評価することにある。本発明者等は、高い集中を処理でき且つリアルタイムに動作できる、膨大な数の命令に対する最適化されたデータ処理アーキテクチャを提供するために、普段はシーケンシャル処理が必要且つ必然である場合に、分散処理の速度を利用する新しいハイブリッドデータ処理アーキテクチャを開発した。] [0057] 本発明の一つの態様によれば、極めて多数の処理命令をリアルタイムに処理及び操作するシステムが提供され、各処理命令は2つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量(額)及びタイプを指定するものであり、該システムは、 複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記複数のプリローダは並列に動作して複数のそれぞれの受信処理命令に対する前記リファレンスデータをマスタデータベースから読み出すように構成され、更に、 複数の前記処理命令をそれらのプリロードされたリファレンスデータとそれぞれ一緒にキューイングするエンリッチ命令キュー、 受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な命令に対して更新コマンドを発生するように構成された実行エンジン、及び 前記実行エンジンからの前記更新コマンドに応答して、前記マスタデータベースを各実行可能な命令の結果で更新する複数のアップデータを備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されていることを特徴とする。] [0058] 本発明の到達時に、本発明者は最初に下記の点を評価した。] [0059] リアルタイム応答を提供するために、本発明の命令処理システムは個別の要求を処理し応答できる必要がある。従って、純粋な「バッチ向け」解決策は極めて効率的であるが、このような解決策を実現することはできない。] [0060] 本発明の命令処理システムは極めて高いスループットに到達しなければならず、この理由のために、十分な数の更新を格納リソースアカウントファイルに対して短い期間内に実行する必要がある。伝統的な従来の並列入力照合アプローチ(図7に示されている)では、リアルタイム処理が可能で、命令プロセッサの多数のインスタンスを並列にランさせることによって増加したスループットを達成できる。しかしながら、システムは高い命令の集中に対処する必要があるため、命令プロセッサの多数インスタンスの並列ランは命令のロッキングを増加するのみとなり、スループットを不都合に低下する。] 図7 [0061] 本発明者は、従来のアプローチに対して新しい特定の特徴の組み合わせが本発明の目的を満足する改善された解決策をもたらすことができることを認識した。新しいハイブリッド解決策によれば、命令をシーケンシャル処理することによって命令へのロッキング影響が阻止される。通常生じるスループットの低下は、実際の処理を最小限に縮小することによって、即ち命令プロセッサは命令それ自体を実行できるかどうかに関する決定を行う必要があるだけとすることによって、防止される。アカウントリソースファイルの更新は命令プロセッサが行う判断から分離され、それから外注されるため、命令プロセッサのスループットが増大する。更に命令を処理決定を行うのに必要なすべてのデータとともにプリロードすることによって、時間を要するデータベースアクセスが命令プロセッサにより避けられる。] [0062] 本発明は単一のシーケンシャル実行エンジンのランに基づくものであるから、処理命令に対するリファレンスデータのプリローディングを必要とする。これなしでは、(プリローダの下流で実行される)単一のシーケンシャル実行エンジンは所望の高スループットに到達できない。これは、実行エンジンは命令を処理するために多くのリファレンスデータの値を読み取る必要があり、読み取り動作がマスタデータベースに対して実行される場合、多数のプロセッササイクルが費やされることになるからである。所望の全体スループットを達成するために、プリローディング機能がマルチインスタンスコンポーネントとして実現され、好ましくは複数のプリローダがマスタデータを複数の命令の各々に対して一つずつ並列に読み取るように設けられる。更に、プリローダはボトルネックを緩和するのに役立つ複数の入力キュー(インスタンス)を有することができ、これらの入力キューの各々は複数のプリローダの対応する一つへの専用の入力を提供するように配置される。並列処理のスケーラビリティはロッキング問題により損なわれない。これは、プリローダ動作は読み取りのみであり、ロッキング問題を生じないためである。] [0063] マスタデータベースはアップデータによってのみリアルタイムに更新される。従って、プリローダのリードオンリプロセスはデータベースロッキングを発生しない利点をもたらす。プリローダは、アップデータのアップデートプロセスにより既にロックされているリファレンスアカウントファイルを読み取ろうとするとき、ちょうど遅延される。プリローダ性能も、有利なことに、並列にランするデータ読み取り機能の新しいインスタンスを追加することによって拡張可能である。] [0064] 本システムは、実行エンジンに格納された現在状態テーブルを更に備え、前記現在状態テーブルは、更新されたリソースアカウントファイルの各々の更新されたリアルタイム値を表すように、前記リソースアカウントファイルに対して実行された命令の結果で更新されるように構成され、実行エンジンは、後続の命令のシーケンシャル処理のために、特定のリソースアカウントファイルに対して、前記現在状態テーブル内の情報を前記プリローダからのリファレンス情報に優先して使用するように構成される。] [0065] 各プリローダはマスタデータコレクタを備え、各マスタデータコレクタはマスタデータベースからデータを読み取るように構成される。この読み取りは非同期プロセスであるため、リファレンスデータの読み取り値は古い可能性がある。しかし、このことは、実行エンジンは、それが初めて情報を受信し、それを現在状態テーブルに格納するとき、マスタデータが正確であることを知っているので、問題にならない。最初の命令が実行される場合、現在状態テーブル内のリソースアカウントファイルの値に対する更新が行われる。しかし、同様に同じリソースアカウントファイをリファレンスする後続の命令も、特定のリソースアカウントファイルに対してマスタデータベースの古い値ではなく正確な更新値を有する現在状態テーブル内の値を有利に用いることができる。] [0066] 現在状態テーブルの可能な最速の実施を確実にするために、実行エンジンは現在状態テーブルを格納する高速ローカルデータメモリを備えるのが好ましい。] [0067] 本システムは、複数の異なるソースからリアルタイム命令及びバッチ命令を受信し、これらの命令を前記複数のプリローダへの入力のためにキューイングするように構成された初期入力キューを更に備えることができる。更に、スループットを助けるために初期入力キューの複数のインスタンスを設けることもできる。初期入力キューは各入力命令に優先順位を指定するように構成するのが好ましい。] [0068] 命令の処理結果が一組の実行規則の違反になるとき処理命令の失敗が生じる。これらの規則は受諾し得ない処理結果の定義又はしきい値を与えるものとし得る。例えば、リソースアカウントの量(額)がゼロより低くなる場合には命令は受諾されない。所定のリソースアカウントに対して、集計リソース値が所定のレベルより低くなるとき、しきい値に達したものとし得る。] [0069] 実行エンジンは各命令の優先順位に従って命令を処理するように構成される。優先順位制御は失敗した命令にも適用し、再利用することができる。そうするために、実行エンジンは、命令が関連する一つのリソースアカウントファイルのバランス(残高)に変化(典型的には増加)が発生したときにサクセスフルに実行可能となる失敗命令の再処理を含む。] [0070] 本システムは処理セッションの間、典型的には1日につき1回のセッションの間動作する。運転可能日の点からすると、セッションの開始は、システムが運転可能でなかった間に処理できなかったプリロードされた命令の実行をトリガする。この初期期間においては、システム動作はバッチ向きである。しかし、処理のために命令のバッチがシステムにより受信されるセッション開期間中でも、システムは新たに入力する非バッチ処理命令をリアルタイムに処理し、それらに優先順位を指定し、それらを関連する優先順位に従って処理するために順序付けることができる。] [0071] 好ましくは、実行エンジンは、失敗した処理命令を高速のローカルメモリに格納し、前記失敗した処理命令により特定されるリソースアカウントファイルの更新が起こった後に、前記失敗した処理命令を再実行のために提示する再利用モジュールを備える。これらの失敗した処理命令は、好ましくは、再利用中おけるにサクセスフルな実行の確率を向上させるために優先順位付けすることができる。より好ましくは、本システムは、小さいリソースアカウントクレジット又はデビットの移動よりも大きな移動を有する命令に高い優先順位を与えるように構成することができる。] [0072] セッション開によりトリガされた命令の大半が完了すれば、システムの動作は純粋にリアルタイムになる。この時間中は、特定のリソースアカウントファイルの値又は特定の集計リソース値の如何なる増加も、当該リソースアカウントファイルの値又は当該集計リソース値が低すぎたために決済に失敗したすべての前命令の再利用をもたらす。この再利用は、上述したように再利用のために格納された命令の各々の予め決められた優先順位に従って実行するのが好ましい。] [0073] 再利用モジュールは、再利用プロシージャ中に、失敗命令をそれらの優先順位の順に格納し、最も高い優先順位の命令を再実行のために供給するように構成するのが好ましい。] [0074] 実行エンジンはすべての失敗命令をそのメモリ内に保持するため、リソースアカウントファイルのレベル又は集計リソースレベルの増加により、その増加を待っているすべての失敗命令の再利用を誘発することができるようにするのが好ましい。実行エンジンはリファレンスデータの増加(変化)を待つそのローカルメモリにこの失敗命令のリストを保持するのが好ましく、このリストの命令を優先順位順に処理することは比較的容易である。] [0075] 再利用モジュールは、前記リスト内の命令に関連するリソースアカウントファイルの現在値を留保し、この留保された量を再利用プロシージャ中に命令の要件をかなえるために使用するように構成されている] [0076] 大きな命令に対するリソースアカウント内の利用可能なリソースを留保してこの量を用いる小さい命令を避けることは、再利用における決済効率を高める。例えば、ある命令は50を要求し(出金)、バランス(残高)は30である。その決済は、20の不足のために失敗する。30の留保は20を要求する小さい命令の決済の実行を阻止する。目的は、20の受領(入金)が起こった場合(別の命令の実行により与えられる)、50の大きな命令を実行するチャンスを与えることにある。この留保オプションは失敗命令に対して維持される。再利用エンジンは、所定のリソースアカウントファイルの残高に増加が発生するとき留保額を増大し得る命令を実行するように試みる。] [0077] 前述したように、命令の再利用は従来の実行エンジンでは実行エンジンの全体性能の低下をもたらすが、上記の動的再利用は効率を大幅に向上するため、実行エンジンの全体性能は、実際上、再利用機能がまったく設けられていない場合より速くなる。] [0078] 実行エンジンはそのメモリに、リソースアカウントファイルおよび集計リソース値の現在値の更新された正確なイメージを保持するので、どのような留保の必要性もローカルメモリ自体内で比較的容易に具体化することができる。実行エンジンの動作は並列処理でないため、命令は優先順位順に受信され、最高優先順位の命令を最初に留保することができる。] [0079] 再利用モジュールは、失敗処理命令を再実行のために所定の最大回数にわたり提示し、この失敗命令が依然として実行されなかった場合に、この失敗命令をキャンセルするように構成することができる。] [0080] 本発明を具体化するシステムは所望の目的を達成するように構成されている。使用アーキテクチャの観点からすると、システムは以下の技術的特徴を有する。] [0081] 本システムはリアルタイムに動作する。エンティティが命令を送ると、フィードバック(命令の成功又は失敗)が典型的には3秒以内に受信される。この経過時間は、受信命令及び応答メッセージをエンティティの通信インフラストクチャとシステムプラットフォームとの間で伝送するのに要する時間と、命令の処理を実行するのに要する時間とを含む。この経過時間は、メッセージを処理プラットフォームまで伝送するための1秒間と、処理プラットフォーム内における実行のための1秒間と、応答メッセージをインフラストラクチャに返送するための1秒間に分けられる。伝送時間は、ネットワークの伝送負荷及び動作状態に依存するので、僅かに変化し得ることもちろんである。従って、上記の時間は一つの命令に関するSSEへの往復に要する平均伝送時間を表す。] [0082] 本発明を具体化するシステムは高いスループットを達成する。具体的には、本システムは、典型的には処理セッションの開始時に起こるピーク時間に、500命令/秒のスループットを達成できる。] [0083] 本発明を具体化するシステムはいわゆる「シンクロナスファイナリティ」を達成する。これは、実行エンジンが命令を処理しているときに、関連するエンティティの結果のリソースアカウント及び集計リソース値のすべてに対する更新が同じ論理作業単位の一部分として実行されることを意味する。] [0084] 本発明を具体化するシステムは、他のアプリケーションによるマスタデータベースのリソースアカウント値へのアクセスを可能にするように構成される。この能力は、本システムがアクティブである間、同じくマスタデータベースを参照する必要がある外部システムの動作にも有益である。] [0085] 本発明のアーキテクチャの設計は非ロック親和性を有するシステムをもたらす。マスタデータベースに対して実行される更新は、実行エンジンが同じリソースアカウントファイルを高いレートで更新するときに性能が影響されないように管理される。本発明のこの特徴は、更新の集中がある場合、例えば特定の集計リソース値が毎秒50回更新される場合に真価を発揮する。] [0086] 本システムは、処理命令のローディング速度を実行エンジンのスループット未満に減速するために、実行エンジンの処理命令スループットを決定し、命令注入プロセス(キュー)に待ち状態を与えるペーシングモジュールを更に備える。更に、実行エンジンが数個の処理モジュールを有し、各処理モジュールが命令をローディングする複数のインスタンスキューを有する場合、ペーシングモジュールは、命令ローディング速度を実行エンジンのスループット未満に減速するために、実行エンジン内の任意の処理モジュールの任意のキューに待ち状態を与えるように構成される。] [0087] メッセージキュー設計において、本システムは如何なる命令キューにも多すぎる命令を格納しないようにする必要がある。実際上、メッセージキューシステムは、命令をデータコンテナのように保持することなく転送するように設計される。データ保持機能はデータベースに留保すべきである。多くの命令をキューイングするとき、命令キューはそれらをメモリに直接保持することはできない。むしろ、この場合には、命令キューはそれらをディスクにアンロードしなければならない。その結果、スループットが大幅に低下する。] [0088] システムに多すぎるメッセージを格納しないように、ページングモジュールは新しい命令がシステムにローディングされる速度を制御する。ローディング速度がキュー設計の最も弱いリンクのスループットより高い場合にキューイングが起こる。ローディング速度を制御するために「ペーシング」というスリープタイムが各コミット後に実行され、所定のレートを超えるロードスループットが防止される。] [0089] 実行エンジンは、受信命令の実行の結果を報告する報告モジュールを備え、前記報告モジュールは、実行できると決定された各命令に対して更新命令を出力し、各失敗命令に対して通知命令を出力するように構成される。] [0090] 本システムは、報告モジュールから更新命令及び通知命令を受信し、キューイングするように構成されたファイナリティキューを更に備えることができる。] [0091] 実行エンジンの実行決定とマスタデータベースの更新との分離は本発明のアーキテクチャにおける従来技術からの主要な変化である。ファイナリティキューへの更新命令の入力により、その命令がファイナルとして宣言される。殆どの従来のバッチシステムは「オール・オア・ナッシング」に基づいて動作する。従って、バッチの終了時にファイナリティに達する。殆どの従来のリアルタイムシステムは、マスタデータベースの変化をコミットすることによりそれらの命令をファイナルとする。本発明では、実行エンジンが更新命令をファイナリティキューへコミットすると同時にファイナリティになる。これは、実行された命令とマスタデータベース内のリソースアカウントファイルの関連値との間にリアルタイム同期がないことを意味する。] [0092] 処理アーキテクチャのこの分離特徴は、複数のプリローダにより読み取られたリファレンスデータが期限切れになり得ることを意味する。本発明は、最初にリファレンスデータが実行エンジンに与えられ、リファレンスデータの値がリファレンスアカウント及び集計リファレンス値の実際の現在状態を正確に反映するようにする。そうするために、好ましくは、システムは、処理セッションを開始する前、即ちプリローダ及び実行エンジンの動作を開始する前に、命令の実行を反映するすべての更新コマンドがマスタデータベースに反映されるようにする必要がある。換言すれば、すべてのキューが処理セッションの開始前に空になるようにする必要がある。] [0093] 報告モジュールは、実行エンジンによる一つの物理的作業単位の完了を表すコミットイベントが起こるまで、複数の更新命令を一時的に格納し、コミットイベントの発生時に複数の格納された更新コマンドを出力するように構成するのが好ましい。] [0094] 設計によって、システム処理ステップは複数のステップを備える。システムの全体スループットは最も弱いリンクにより制限される。プロセスのステップが並列処理によるスケーラビリティを有するとき、それは最も弱いリンクになり得ない(性能は他のステップを同時にランさせることにより常に高めることができる)。その結果、システムの最も弱いリンクはシーケンシャル実行エンジンである。というのは、並列処理をサポートしないシステム内の唯一のコンポーネントが実行エンジンでからである。] [0095] 実行エンジン、ひいてはシステムの性能を改善するためには、不必要な外部データアクセスを避けることによって実行エンジンの操作をできる限りCPUバウンドとして維持するようにすべてのことを実行しなければならない。複数のプリローダを用いることによって、実行エンジンにより必要とされるすべての読み取りデータが命令とともにプリロードされ、出力において、実行すべきすべての更新命令が単一の命令メッセージに束ねられる。結局、実行エンジンの外部データアクセスは入力において一つの永続的メッセージに限定され、出力において一つの永続的メッセージに限定される。他のデータアクセスの付加が可能であるが、システムの全体スループットを低下する不利がある。] [0096] 性能を改善するためには、実際の命令実行以外のロジックを実行するCPUサイクルの活動を避けるようにすべてのことを実行しなければならない。例えば、CPUサイクルはコミット時間中活動する。従って、実行エンジンは(コミットプロセスを実行する前に(ローカルメモリ内の)複数の入力命令を実行する)一組の論理的作業単位を束ねる一つの物理的作業単位を実行する。50のコミット周波数の場合、500命令/秒のスループットは500コミット/秒の代わりに10コミット/秒をもたらす。コミットプロセスは実行エンジンに対する物理的作業単位を表す。50のコミット周波数は50の処理命令が実行され、報告されることを意味し、それは、実行されたすべての更新の最後(入力する命令の物理的除去及び報告メッセージの物理的書き込み)を与える技術的コミットフェーズがエンタリングされるためである。] [0097] 本システムは、好ましくは、ルーティングフレームワークを更に備え、このルーティングフレームワークは、命令を同時に動作する複数の初期入力キュー又は更新インスタンスキューに分散するように構成される。これにより、命令を均等に分散することができ、複数の異なるキュー又は処理素子を例えばプリローダ及びアップデータに使用することができる。] [0098] ルーティングフレームワークは、好ましくは、命令が関連する情報のタイプを記述する命令名及び命令を特定する一意のキーを提供するワークロードバランサキーを命令に指定するように構成することができる。この場合には、ルーティングフレームワークは、受信した命令及びワークロードバランサキーを用いて複数の入力キュー又は更新インスタンスのうちの一つを選択するように構成することができる。] [0099] ルーティングフレームワークは、前記ルーティングフレームワークと共同して、前記受信命令名及びワークロードバランサキーを用いて、前記複数の初期入力キュー又は分離入力キューのうちの一つの選択するように構成されているワークロードバランサを備えるのが好ましい。] [0100] 所望のスループットを達成するために並列処理を用いるシステムの各コンポーネント(例えばプリローダ及びアップデータ)に対して、ワークロード(作業負荷)はワークロードバランサ及びルーティングフレームワークによってこれらのコンポーネントの各々に正しく分散される。しかしながら、この分散は、有利なことに、入力命令を実行すべき順序を規定する順序付けルールの違反を生じない。] [0101] ルーティングフレームワーク及びワークロードバランサは、ワークロードを一組のキュー(例えばマスタデータ分離キュー)に分散し、同じ順序付けキーを有する命令が同じキューに経路指定されることを保証することができる。ルーティングフレームワークは、使用可能なインスタンスの数を分析し出力メッセージを順序付け制約を破ることなく分散させることによって、それ自体を目標プロセスの構成に直接適応させることができる。] [0102] 換言すれば、ワークロードバランサは、特定のリソースアカウントデータファイルに関連するすべての命令が常に複数のキューのうちの同じ一つに経路指定されるようにするために、所定のワークロードバランサキーを同じ特定の宛先にリンクするように構成される。] [0103] 好ましくは、本システムは、所定の時刻における処理セッションの終了に応答して、メッセージを実行エンジンの出力に設けられたキューの入力に送り、その応答を待ち、更なるメッセージを複数のアップデータの一つの入力キューに送り、その応答、即ち処理セッションの終了前に実行された処理命令のすべての結果によるマスタデータベースの更新を示すシーケンシャル応答の受信を待つように構成されたデリミタフレームワークを更に備える。] [0104] 本システムが各処理命令の結果を報告するディスパッチャモジュールを備える場合には、デリミタフレームワークは、処理セッションの終了前に実行された処理命令に対する報告メッセージがすべて送られたことを確認するために、メッセージをディスパッチャの入力キューにも送り、それぞれのフィードバックを待つように構成するのが好ましい。] [0105] 換言すれば、デリミタフレームワークは、実行エンジンの出力部、即ちファイナリティキューにメッセージを送る。デリミタフレームワークがこのメッセージに対する応答を受信すると同時に、それはデリミタメッセージの到達前にファイナリティキューに格納された命令のすべてが処理されたことを示す。その後、デリミタフレームワークはディスパッチャの各インスタンスにメッセージを送り、各インスタンスからの対応するフィードバックを待つ。ディスパッチャのすべてのインスタンスからそれらの関連するフィードバックがデリミタフレームワークに送られたとき、デリミタフレームワークは、すべてのディスパッチプロセス(命令、実行、結果及び報告)が終了したことを知る。このとき、デリミタフレームワークはデリミタプロセスをアップデータに対して開始することができる。これは、マスタデータアップデータの各インスタンスにメッセージを送り、すべてからの関連するフィードバックを待つことにより行われる。] [0106] マスタデータアップデータのすべてのインスタンスからのフィードバックが受信されると、デリミタは、期限前にポジショニングエンジンにより実行された処理命令に関連するすべての命令の更新が今マスタデータベースに反映されたことを知る。デリミタのワークフローは終了し、セッション活動報告がディスパッチャにより発生される。] [0107] 本発明は、極めて多数の処理命令を処理セッション中にリアルタイムに処理及び操作するコンピュータ実行方法にも及び、各処理命令は2つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該方法は、 複数のプリローダから処理命令に関連するリファレンスデータを取得するステップを備え、各プリローダは前記処理命令に関連するリファレンスデータをそれぞれ取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記取得ステップは、複数のそれぞれの受信処理命令に対してマスタデータベースから前記リファレンスデータを読み出すために前記複数のプリローダを並列に動作させるステップを含み、更に、 複数の前記処理命令をそれらのプリロードされたリファレンスデータと一緒にエンリッチ命令キューにてキューイングするステップ、 実行エンジンによって、受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な命令に対して更新コマンドを発生するステップ、及び 前記実行エンジンからの前記更新コマンドに応答する複数のアップデータを用いて、前記マスタデータベースを各実行可能な命令の結果で更新するステップを備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されていることを特徴とする。] [0108] 本発明の更に別の態様によれば、極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムが提供され、各処理命令は2つの異なるエンティティに関するデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該システムは、 複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記複数のプリローダは並列に動作して複数のそれぞれの受信処理命令に対してマスタデータベースから前記リファレンスデータを読み出すように構成され、更に、 複数の前記処理命令メッセージをそれらの取得されたリファレンスデータと一緒にキューイングする命令メッセージキュー、 各命令メッセージをシーケンシャルに実行する実行エンジンであって、任意のマスタデータベースアクセスを用いる代わりに前記プリロードされたリファレンス情報を用いて、前記命令メッセージを当該ファイルの現在状態の下で実行できるかどうかを決定するように構成されている実行エンジン、及び 関連するファイルの更新されたリアルタイムポジションを確定するためにファイルに対して実行された命令の結果で更新されるように構成された現在状態テーブルを備え、 前記実行エンジンは、特定のデータファイルが処理セッション中に実行エンジンにより更新された場合に、後続の命令のシーケンシャル処理のために、当該データファイルに対して、現在状態テーブル内の情報を前記複数のプリローダからのリファレンス情報に優先して使用するように構成されていることを特徴とする。] [0109] 本発明のこの態様は、最新のリソースアカウント値のリアルタイム更新可能コピーを実行エンジンのメモリに持たせることによってマスタデータベースの更新を避けることを目的としている。これは、膨大な数の命令をリアルタイムに処理する従来技術の問題の大半を克服する重要な設計上の特徴である。] [0110] 本発明の更に別の態様は、異なるレートで非同期的に受信される極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムが提供され、該システムは、 命令メッセージに対して異なるタイプの処理を実行する複数の処理モジュールを備え、各処理モジュールは命令メッセージをシーケンシャルに処理するように構成された実行エンジンを備え、更に 各組がそれぞれのデータ処理モジュールへの入力をキューイングするように設けられた複数組の命令キュー、及び 実行エンジンの処理命令スループットを決定し、処理命令のローディング速度を実行エンジンのスループット未満に減速するために任意の命令キューに待ち状態を与えるペーシングモジュールを備えることを特徴とする。] [0111] 前述したように、異なるレートで非同期的に受信される極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムは、任意の命令キューに多すぎる命令が格納されるのを避ける必要がある。メッセージは格納(データベースの機能)されるよりも転送されることになる。キューイングされる命令の数が多くなると、それらをディスクからアンロードしなければならず、これは時間のかかる処理であり、スループットを直接低下させる。] [0112] システムに多すぎるメッセージが格納されるのを避けるために、ペーシングモジュールがシステムにロードされる新しい命令の速度を好都合に制御する。ローディング速度がキュー設計の最も弱いリンクのスループットより高い場合にキューイングが起こる。ローディング速度を制御するために、「ペーシング」というスリープ時間が各処理時間単位後に実行され、所定のレートを超えるロードスループットが防止される。] [0113] 本発明の更に別の態様によれば、極めて多数の処理命令メッセージを処理セッション中にリアルタイムに処理及び操作するシステムが提供され、各処理命令は2つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該システムは、 複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの現在値を示し、前記複数のプリローダは並列に動作してマスタデータベースから前記リファレンスデータを読み取り、前記リファレンスデータを前記処理メッセージと一緒に実行エンジンに出力するように構成され、 前記実行エンジンは、各命令メッセージをシーケンシャルに実行するように構成され、任意のマスタデータベースアクセスを用いる代わりに前記プリロードされたリファレンス情報を用いて、前記命令メッセージを当該ファイルの現在状態の下で実行できるかどうかを決定するように構成され、更に 関連するファイルの更新されたリアルタイムポジションを確定するためにファイルに対して実行された命令の結果で更新されるように構成された現在状態テーブルを格納する高速ローカルメモリ、及び 失敗した処理命令のリストを高速のローカルデータストアに格納し、前記失敗した処理命令により特定されるリソースアカウントファイルの更新が起こった後に、前記失敗した処理命令が再実行のために提示される場合に、再利用プロシージャを実行する再利用モジュールを備えることを特徴とする。] [0114] 好ましくは、前記再利用モジュールは、前記失敗命令をそれらの優先順位の順に格納し、再利用プロシージャ中に最高優先順位の命令を再実行のために最初に提示するように構成される。この構成は、異なる特性の命令を最大のスループットで効率よく操作する最適な操作法を提供する。] [0115] 前記再利用モジュールは、前記リスト内の命令に関連するリソースアカウントファイルの現在値を留保し、この留保された量を再利用プロシージャ中に命令の要件をかなえるために用いるように構成することができる。この構成により、リソースに対して起こり得るデマンドが重要な期限の失敗を防止するために早い段階で識別されるようになる。] [0116] 更に、前記再利用モジュールは、失敗処理命令を再実行のために所定の最大回数にわたり提示し、この失敗命令が依然として実行されなかった場合に、この失敗命令をキャンセルするように構成するのが有利である。この構成によれば、実行しようとしていないトランザクションによりシステムが停滞する問題を防ぐことができる。] [0117] この動的再利用発明の利点は上で再利用モジュールに関連して既に説明されているため、ここでは繰り返さない。] [0118] 本発明の特定の実施例を添付図面を参照して以下に説明する。] 図面の簡単な説明 [0119] パーティA及びパーティB間で契約を実行する基本的な従来の命令処理構造を示す概略図である。 マスタデータベースに格納されるリソースアカウントファイルを示す概略ブロック図である。 パーティからのデータメッセージ命令の構成を示す概略ブロック図である。 図1の命令実行サーバの主なコンポーネントを示す概略ブロック図である。 従来の命令処理プラットフォームの一般的な動作を示すフローチャートである。 従来の命令処理プラットフォームの一般的な動作を示すフローチャートである。 バッチ入力に対する標準的な従来の照合プロセスを示す概略図である。 並列複数入力プロセスに対する標準的な従来の照合プロセスの概略図である。 本発明の一実施例による処理プロセスラットフォームを示す概略ブロック図である。 図8の処理プラットフォームの動作を示すフローチャートである。 図8の処理プラットフォームのプリローダの動作を示すフローチャートである。 図8の処理プラットフォームのポジショニングエンジンの概略ブロック図である。 図11のポジショニングエンジンの動作を示すフローチャートである。] 図1 図11 図8 実施例 [0120] 本発明の一実施例による処理プラットフォーム150を図8−図12を参照して以下に説明する。処理プラットフォーム150は図2及び図4につき述べたものと同様の命令実行サーバ22内に存在し、一般に従来の命令実行サーバ22に機能的に等価である。もっと正確にいうと、以下に記載する本実施例の処理プラットフォーム150は図4に示される従来の命令検査、実行及び更新エンジン70にとって代わるものである。] 図12 図2 図4 図8 [0121] 図8から明らかなように、処理プラットフォーム150は4つの主なコンポーネント、即ち複数のプリローダ152、ポジショニングエンジン154、ディスパッチャ156及びアップータ158からなる。これらは、図8に示されるように、以下に記載するキュー及び他の機能モジュールと一緒に構成される。] 図8 [0122] プリローダ152は、全パーティのリソースアカウントファイル30及び集計リソース値32のマスタデータベース24へのリードオンリーアクセスを有する。図8では、便宜上、マスタデータベース24はプリローダ152の一部分として示されている点に留意されたい。しかし、一つのマスタデータベース24がシステム内にあるのみであるときは、プリローダ152はマスタデータベース24を含まない点に留意されたい。各プリローダ152は、自分専用の初期入力キュー164からの命令にアクセスするように機能し、所要の情報をマスタデータベース24から取得するマスタデータコレクタ182(後記される)を備え、結果をエンリッチド命令キュー166に出力するように機能する。各プリローダ152はマスタデータコレクタ182を備える(しかし、図8は簡潔のために全部で2つしか示していない)。データコレクタ182は入力決済命令を操作するモジュールであり、各入力コマンドが単一のマスタデータコレクタ182に指定される。マスタデータコレクタ182の機能は、マスタデータベース24から該コマンドに対して適切なマスタデータを読み出し、これらをもとの決済命令と一緒に組み合わせてエンリッチドメッセージ命令(図示せず)を形成し、これを各プリローダ152から出力する。これらのプリローダ152はすべてそれらの動作を並列に実行し、データベースコンフリクト、例えばロッキングを少しも生じず、またリードオンリーデータベース動作を実行するのみであるから、プリローダ152(従ってマスタデータコレクタ182)の数はスケーラブルである。マスタデータベース24は絶えず更新されるが、マスタデータベースの更新機能と読み出し機能を分離することによってこれらの従来の問題が回避され、また処理セッションにおける最初の読み出し後に読み取られるリソースアカウント値30は正確である必要もなくなる。] 図8 [0123] ポジショニングエンジン154はシングルインスタンス論理プロセッサ184及び更新されたマスタデータレコードテーブル186を備え、該レコードテーブルはプロセッサのメモリに格納される。更新されたマスタデータレコードテーブル186はマスタデータベース内のリソースアカウントファイルに対応する複数のファイル30aを備える。しかし、図11から明らかなように、また後で説明されるように、リソースアカウントファイル30のすべてが対応するファイル30aを有するとは限らない。] 図11 [0124] シングルインスタンス論理プロセッサ184はプリローダ152で生成されたエンリッチ命令を受信し、これらの命令を一つずつ処理して、それが基づく決済命令をコミットすべきかロールバックすべきかを決定する。基本的には、各パーティに対するリソースアカウントファイル30の値及び集計リソース値32が、決済命令の実行後に、受入可能である(即ち実行規則72を満足する)場合、決済命令は受け入れられる。この決定を行うために、シングルインスタンス論理プロセッサ184は、更新済みマスタレコードメモリテーブル186の対応するファイル30aを、受入可能な決済命令に由来するリソースアカウントファイル30の各々の最後に更新された値(最新の更新値)で連続的に更新する。リソースアカウントファイル30aのこれらの更新値はその後受信されるエンリッチ命令に含まれる対応する値に優先して使用される。ポジショニングエンジン154の出力は、ポジショニングエンジン154に入力された決済命令とその命令が受入可能、即ちコミットすべきか、受入不能、即ちロールバックすべきかどうかの指示のリストである。更に、ロールバックされる命令は保持され、再利用することができ、この点については後に詳述する。命令の主部でないリソースアカウントファイル30はマスタレコードメモリテーブル186に対応する写しを持たないので、メモリのサイズはデータベースのサイズより小さくなる。] [0125] ディスパッチャ156はディスパッチャモジュール188を備える。ディスパッチャモジュール188は、ポジショニングエンジン154から出力される、処理された決済命令のリストを受け取り、処理の結果(コミット又はロールバック)を決済命令と関連するパーティに報告する。ロールバックされる命令に対しては、失敗の理由が応答メッセージに記述される。コミットされる命令は、サクセスフルに処理される決済命令として報告され、それらはアップデータ158に渡される。] [0126] アップデータ158は、マスタデータベース24の固有の部分にそれぞれアクセスすることができる複数のマスタデータアップデータ190を備える。簡潔のために、図8はマスタデータベースの3つの部分24a,24b,24cにアクセスする3つのマスタアップデータ190を示す。しかし、本例では、これはプラットフォーム150のスケーラブル部分であり、マスタアップデータ190及び関連する固有の部分24a,24b,24cの多数倍が設けられる。成功決済命令がマスタアップデータにどのように分散されるかは後に詳述される。] 図8 [0127] 処理プラットフォーム150への入力は、決済命令のバッチ160を入力としてそれぞれ供給する複数のシーケンスファイル操作プロセス160およびリアルタイムに受信しリアルタイムに処理すべき決済命令を操作する一つ以上の個別命令操作コンピュータ又はプロセス162から与えられる。] [0128] 処理プラットフォーム150の主なコンポーネントの間にはキューモジュールが設けられる。これらのキューは、場合により、同時プロセス領域をシーケンシャルプロセス領域へ及びその逆に変換する手段として作用する。もっと正確に言うと、複数のシーケンスファイル操作プロセス160及び個別命令操作プロセス162から受信し得る非同期の決済命令をキューイングするために複数の初期入力キュー164が複数のプリローダ152の入力として設けられる。プリローダ152のマスタデータコレクタの同時動作の結果を照合し、これらをポジショニングエンジン154へ入力すべくシーケンシャル領域に変換するために、エンリッチ命令キュー166が設けられる。ポジショニングエンジン154の出力はファイナリティキュー168に接続され、これはディスパッチャ156への入力としても作用する。最後に、複数のマスタデータ分離キュー170がディスパッチャ156の出力とアップデータ158の複数の入力との間に設けられる。ディスパッチャ156の別の出力はリプライキュー172に接続され、リアルタイムメッセージを命令操作プロセス162に供給する。] [0129] 誤解を避けるために、初期入力キュー164、エンリッチ命令キュー166、ファイナリティキュー168、マスタデータ分離キュー170及びリプライキュー172は、図8に明瞭に示されているように、すべて複数のインスタンスで与えられ、即ち複数のキューが並列に動作する点に留意されたい。] 図8 [0130] 処理プラットフォーム150中の命令の流れを助けるために3つの他のモジュールが設けられる。ペーシングモジュール174は、バッチプロセス160からの命令がキューイングされるレートをプラットフォーム150中の最も弱いリンクより低いレートに調整する。こうすると、プラットフォーム150内のキューは常に殆どからになる。] [0131] ルーティングフレームワーク175はワークロードバランサ176を介して命令をキューへ経路指定するために使用される。ルーティングフレームワークはフレキシブルであって、経路指定の種々の態様を受信命令の順序付けを変えることなく変えることができる。] [0132] ワークロードバランサ176は、命令のワークロードを一組のキューへ分散させ、同じキューイングキー(後述する)を有する命令/コマンドが同じキューに経路指定されるようにするために使用される。] [0133] デリミタフレームワークモジュール178は、ポジショニングエンジン154により実行され、所定の期限日までにファイナリティキュー168に書き込まれた全処理がマスタデータベース24及び更新を確認するリアルタイムメッセージに反映されるようにするために使用される。] [0134] 次に図9を参照して、処理プラットフォーム150の全操作プロセス200が説明される。プロセス200は、決済命令がステップ202において非リアルタイムのバッチファイル160又はリアルタイムの個別命令操作プロセス162のいずれかから受信される状態で開始する。非リアルタイムバッチファイルは、例えば特定の未来の実行日を有する命令を繰り返し格納することにより生成することができ、バッチは特定の実行日の到達時に実行されるように生成される。ここで使用される語「バッチ」は、レコードを特定の順序に配列する必要があることを意味しない。本例にとって、バッチ内の決済命令の順序は問題にならない。むしろこの語は単に一群の決済命令を示すために使用される。] 図9 [0135] プロセス200は、ステップ204において、受信命令を次にそれぞれのプリローダ152に入力するために初期入力キュー164においてキューイングする。このキューイング204は決済命令のフローを非同期並列入力領域から同期シーケンシャル領域へ変換する。次にこれらの命令は、各命令に対するリファレンスデータをマスタデータベース24から取得するために、ステップ206において複数のプリローダ152により処理される。このプロセスは複数のマスタデータコレクタ182(各プリローダにつき一つ)を用いて並列に実行される。] [0136] 各決済命令について、ステップ208において、取得した情報を照合して、決済命令自体と、該命令を実行規則72に違反することなく実行できるかどうかを決定するためにポジショニングエンジンにより必要とされるマスタデータベースのリファレンスデータとを含むエンリッチ実行命令を生成する。エンリッチ実行命令のすべては、同様にステップ208において、エンリッチ命令キュー166内に置かれる。ここでも、エンリッチ命令キュー166は、並列に動作する複数のマスタデータコレクタ182の出力を処理すべきシーケンシャルエンリッチ決済命令のリストに変換するように機能する。] [0137] 次に、ポジショニングエンジン154がステップ210においてキューイングされたエンリッチ決済命令の各々を順番にシーケンシャル処理する。このプロセスの詳細は後に記載される。しかしながら、ステップ212において決済命令を規則72に違反しないで実行できるかどうかの決定が行われる。答えが否定の場合、決済命令はステップ214において再利用され、ステップ216においてディスパッチャ通知メッセージが生成される。このメッセージは、決済命令は不成功であったが将来再利用可能であることを示す。] [0138] ステップ212において答えが肯定の場合には、決済命令はステップ218において実行され、局所的に格納されている更新されたマスタレコードメモリテーブル186の対応するファイル30aが当該決済命令に含まれるパーティに対するリソースアクセスファイル30及び集計リソース値32の新しい値で更新される。次に、実行された決済命令は、ステップ220において、ディスパッチャ156への供給及び次のアップデータ158への転送のために、ファイナリティキュー168に更新実行命令として格納される。図9には示されていないが、再利用される命令もファイナリティキューに入力される。これらの失敗した命令もファイナリティキューに置かれるが、報告のためのみであり、これらはアップデータ158に渡されない。] 図9 [0139] ディスパッチャ156はファイナリティキューに格納された命令を読み出し、ステップ222において、命令が成功したかどうかを示す報告メッセージを生成し、該メッセージは決済命令により特定されるパーティに送られる。これらのメッセージは更に、ステップ222において、決済命令のパーティの命令操作プロセス162へのリアルタイム出力のためにリプライキュー172にも送られる。その後、リプライキュー内のメッセージがステップ224において出力される。] [0140] ファイナリティキュー168内のサクセスフルに実行された更新実行命令に対して、ディスパッチャ156は更にステップ226においてこれらの更新命令を複数のマスタデータ分離キュー170に渡す。このプロセスは、後に詳述されるように、ワークロードバランサ176及びデリミタフレームワーク178からの入力を含む。] [0141] 最後に、各マスタデータアップデータ190に割り当てられたマスタデータベース24の部分24a,24b,24cがステップ228においてアップデータ158により更新される。] [0142] 処理プロセス150の重要なコンポーネント及びそれらの機能は以下に詳細に説明される。 初期入力キュー164はプラットフォーム150の公衆インタフェースである。これにより個別命令操作プロセス162から到来する入力フロー(この入力フローに対してはリアルタイムのリプライが期待される)を複数のシーケンシャルファイル操作プロセス160からのバッチフロー(このフローに対しては極めて高いスループットが期待される)と融合することができる。ペーシングモジュール174は初期入力キュー164への入力を制御する。ペーシングモジュール174はバッチ命令のローディング速度をプラットフォームの最低スループットのコンポーネント(典型的にはポジショニングエンジン154)より低い速度に制限する。バッチ命令の場合、初期入力キューにおけるバックログの生成を避けるためにローディング速度を制限する必要がある。個別命令操作プロセス162からのローディング速度は、新しい命令を入力するユーザコンピュータのリアルタイム性能により制限される。初期入力キュー164のこのローディング制御はプラットフォーム150内のすべてのキューに適用される。] [0143] ペーシングモジュール174は、一群の命令を処理する際(例えば、マスタデータベースからの抽出又はファイルベースのバッチ処理の際)に起動される。図8では、ペーシングモジュール174はシーケンシャルファイルと初期入力キュー164との間のフローの最上部で使用される。その機能は、クルーズ制御と同様で、初期入力キュー164へのバッチ命令の注入速度を(最も弱いリンク段部において)命令フローに待機が生じるのを避けるために制限する。] 図8 [0144] プラットフォーム150におけるキュー入力速度の制御には2つの主な理由がある。第1の理由は、メッセージキュー164,166,168,170は実効的にトランスポート層であり、データコンテナでない。キューに格納できるメッセージ又は命令の数は限定されている。バックログの生成はキューの満杯状態をもたらし、キューへの書き込みのためのローディングプロセスを阻止し得る。更に、多数のメッセージをキューに格納するとき、メッセージキューイング性能が低下する。これは、メッセージデータのディスクのアンロードがしばしば要求されるためである。] [0145] ローディングプロセスを制御する第2の理由は、個別命令操作プロセス162から到来するリアルタイム命令は一群のバッチ命令が滞ってキューイングされないようにする。リアルタイム要求がキューイングされると、個別命令操作プロセス162に対する応答時間は2秒の最大応答時間に設定されるリアルタイム応答要件に適合し得ない。] [0146] ペーシングは2つの順次のコミット間の最小遅延で規定される。一つのコミットの実行後に、該コミットの実行時刻と前コミットの実行時刻との間の差分時間が計算される。] [0147] 例: 現在コミット=2007-07-01-09.05.04.224335 前コミット=2007-07-01-09.05.04.100635 2つのコミット間の経過時間(差分)は0.123700である。] [0148] 2つのコミット間のペーシングが0.5秒である場合、0.3763秒の遅延が達成される。コミット周波数が50で、ペーシングが0.5秒である場合、期待されるスループットは100命令である。] [0149] 初期入力キュー164への入力はメッセージルーティング機能を実行するルーティングフレームワーク175及びワークロードバランサ176により操作され、メッセージを所定の数の初期入力メッセージキュー164に均等に分散するワークロード分散技術フレームワークが提供される。] [0150] バッチファイル160から到来する命令とリアルタイムチャネル162から到来する命令との間には区別はない。プラットフォーム150に対する動作時間窓(動作セッション)の開始時に、ペンディング中の格納命令を順序付け、初期入力キュー164に注入する必要がある。開始注入が実行される間、リアルタイムに到来する命令に順序付け規則も適用される。リアルタイム命令はそれらの優先順位に基づいて初期入力キュー164に注入されなければならない。開始時間窓の開始プロシージャが終了するとき、継続中の順序付けは時間ベースである。同じパーティの同じリソースアカウントファイル30に関連する2つの命令は(順々に処理するために)同じ初期入力キュー164に注入されなければならない。] [0151] 複数の初期入力キュー164に対して、これらのインスタンスを並列に実行することは、例えば処理セッション(動作時間窓)の開始時に供給される大量の初期命令を操作するために重要である。ここでルーティングフレームワーク175が命令を複数の初期入力キュー164にロードする責任を持ち、ワークロードバランサ176がワークロードを初期入力キュー164の間で均等に分散させることができる。] [0152] プリローダ152の各々は初期入力キュー164のうちの対応する一つから決済命令を読み出すように構成される。その目的は、入力する決済命令を解析して、該決済命令を実行すべきか否かを決定するためにポジショニングエンジン154により必要されるリファレンスデータをマスタデータベース24から読み出すためである。リファレンスデータは決済命令に含まれるパーティに対する任意のリソースアカウントファイル30及び集計リソース値の現在値である。次に、この読み出されたデータは入力決済命令のみならずマスタデータベース24から読み出されたリファレンスデータのすべてを含むエンリッチ命令を生成するのに使用される。] [0153] 図10は、複数のプリローダ152のうちの一つの動作を詳細に示す。明らかなように、各プリローダ152はスループットを大きくするために独立に並列に動作する。] 図10 [0154] プリローダ152の動作プロセス240はステップ242において開始し、当該プリローダインスタンス152に専用の初期入力キュー164から決済命令を読み出す。次にステップ244において、プリローダインスタンス152のマスタデータコレクタ182が、各パーティのリソースアカウントファイル30及び当該パーティに対する集計リソース値32のデータベース読み取りを決定する。これらの読み取り命令のすべてが計算されたら、データベースの読み取りがステップ246において順に実行される。その後、読み取られたデータがステップ248においてプリローダインスタンス152により処理され、当該命令に対するリファレンスデータが順に配列されたイメージを生成する。次に、このイメージはステップ250においてもとの命令と結合されて複合エンリッチ命令を形成する。プリローダ動作プロセス240はステップ252において各プリローダインスタンス152の複合エンリッチ命令を単一のエンリッチ命令キュー164に出力して終わる。] [0155] ポジショニングエンジン154は、本例の革新的な構成の重要な要素の一つを実施するものであり、はっきり言うとポジショニングエンジン154のメイン論理プロセッサ184は命令を並列に実行しない。メイン論理プロセッサ184はシングルインスタンスとしてランするため、それ自身で全体スループットに達しなければならない。これはメイン論理プロセッサ184のタイムクリティカル動作の重要性を高める。可能な最大スループットを達成するために適用される所要の制約の一つは、データベースアクセスはスループットの低下をもたらすためにこれを禁止する必要があることである。メイン論理プロセッサ184がよく使われる静的リファレンスデータを取り出すことができる初期ローディング後は、プロセッサ184への及びからのデータアクセスは一つの命令の入力及び一つの処理結果の出力に制限される。しかし、命令を処理するために必要とされるが、始動フェーズ中にロードされないリファレンスデータが、各エンリッチ命令の一部分として供給されるリファレンスデータが順に配列されたイメージによって使用可能にされる。プリローダ152の一つから受信される所定のリソースアカウントファイル30に対するリファレンスデータの最初のイメージのみがポジショニングエンジン154によって、アップロードされたマスタレコードメモリテーブル186の対応するファイル30aに格納される。この最初のコピーは命令のリアルタイムフローによりまだ変更されてないために常に有効である。] [0156] アップロードされたマスタレコードメモリテーブル186の対応するファイル30aに既に存在するとき、プリローダ152の一つにより取り出されたリファレンスデータのイメージは、おそらく期限切れである(ポジショニングエンジン154により確認された更新はまだマスタデータベースに反映されていない)ため、単に無視される。従って、リソースアカウントの値に関連するリファレンスデータがアップロードされたマスタレコードメモリテーブル186の対応するファイル30aにおいて入手可能であるとき、このリファレンスデータがエンリッチ命令とともに供給されるリファレンスデータイメージに優先して使用される。] [0157] 次に図11を参照すると、ポジショニングエンジン154の構成が詳細に示されている。ポジショニングエンジン154は、エンリッチ命令キュー166からのエンリッチ命令を受信する命令受信モジュール260及び現在のエンリッチ命令をタイムスタンプするタイムスタンプモジュール262を備える。ポジショニングエンジン154のシングルインスタンス論理プロセッサ184は、リファレンスデータ読み出し及び更新モジュール264、移動カルキュキレータ及びローカルメモリストアアップデータ266及び命令処理ロジック268を含む。] 図11 [0158] リファレンスデータ読み出し及び更新モジュール264は、更新されたマスタレコードメモリテーブル186の対応するファイル30aに格納されているデータを読み出し、該データを更新すべきか決定し、そうであれば該データを更新するように作用する。アップロードされたマスタレコードメモリテーブル186はシングルインスタンス論理プロセッサ184に対して高速ローカルメモリストア270内に与えられ、その結果ポジショニングエンジン154に対して速いデータ読み取り及び書き込み時間が得られる。従って、命令の実行の決定は、時間のかかる外部データベースチェックよりもむしろ、高速のローカルメモリ内データチェックのみで実行することができる。データストア270は決済を後刻再度試みる必要がある失敗命令の再利用リスト272も保持する。] [0159] 移動カルキュレータ及びローカルメモリストアアップデータ266は、アップロードされたマスタレコードメモリテーブル186の対応するファイル30a内の格納リファレンスデータを読み出し、命令情報を用いて該データをどのぐらい変化(移動)させる必要があるか決定し、更新されたリファレンスデータをアップロードされたマスタレコードメモリテーブル186に書き戻すように作用する。] [0160] 命令処理ロジック268は、リソースアカウントファイル30及び集計リソース値32の更新された値が該リソースデータに対する受け入れ可能ポジションになるかどうかを評価するために設けられる。即ち、リソースアカウントファイル30及び集計リソース値32の値が規則72に従うかについて評価される。] [0161] 再利用モジュール274は、失敗した命令を再利用リスト272に読み書きするために設けられ、該リストは次に命令処理ロジック268により又はから読み出し又は書き込むことができる。シングル命令論理プロセッサ184の出力は報告モジュール276に出され、該モジュールは命令処理の結果を更新実効命令としてファイナリティキュー168に出力する。] [0162] 再利用は入力する命令の優先順位に基づく。優先順位グループ分け(例えば高優先順位、標準順位及び低優先順位)が各命令に指定される。再利用モジュール274は再利用イベントの生起に備えて再利用リストに優先順位順に維持される。その順序は主として各命令に指定された優先順位グループ分けに基づいて決定される。その後、命令のサイズが優先順位付けに利用される。再利用リスト内に優先順位を維持することによって、再利用の実施はランタイム中に比較的簡単に、従って高速に行われる。更に、再利用プロシージャは動的に行われ、受信処理命令を再実行する順序を各処理命令の優先順位を反映するように変えることができる。] [0163] 再利用モジュール274は特定の命令とともに処理するためにリソースアカウントファイル30の内容を留保する機能も有する。これは、リソースアカウントファイル内の使用可能なリソースの額が格納された処理命令272の要求を満たすときに起こる。この額を留保することによって、再利用モジュール274は、優先順位が維持されるとともに、大きな高優先順位の命令ではなく小さい低優先順位の命令を実行することができる資金がたとえあっても、大きな高優先順位の命令が小さい低優先順位の命令の前に実行されるようにすることができる。] [0164] これは、ポジショニングエンジン154内の再利用モジュール274が受信処理命令の留保及び優先順位操作をどのように実施するかを示す下記の非限定的実施例に最もよく示されている。] [0165] 実施例: リソースアカウントファイルAcc/Sec1は50の担保(security)を含む。 Acc/Sec1に下記の影響を与える処理命令が順に受信される: ステップ1高優先順位命令1は200を要求する(出金) ステップ2標準優先順位命令2は100を要求する(出金) ステップ3 標準優先順位命令3は150を要求する(出金) ステップ4 標準優先順位命令3は60を持ち込む(入金) ステップ5 高優先順位命令4は290を持ち込む(入金)] [0166] メモリ構造(Acc/Sec1の残高及び再利用リストの内容)はAcc/Sec1の再利用リストを次のように表す: ステップ1後 Acc/Sec1 −50を含む −既に留保 −50に対して命令1 −失敗リスト<命令1>] [0167] ステップ2後 Acc/Sec1 −50を含む −既に留保 −50に対して命令1 −失敗リスト<命令1,命令2>(ins 2はins1より低い優先順位)] [0168] ステップ3後 Acc/Sec1 −50を含む −既に留保 −50に対して命令1 −失敗リスト<命令1,命令3,命令2>(ins 3はins 2と同じ優先順位であるがins 3より大きく、重要である)] [0169] ステップ4後:Acc/Sec1の残高の増加が失敗命令の再利用を可能にし、新しい60の担保を命令1の留保に加えることができる。留保は命令2(100を要求するのみ)がリソースアカウントAcc/Sec1内の使用可能な110の担保を使用するのを阻止する。 Acc/Sec1 −110を含む −既に留保 −110に対して命令1 −失敗リスト<命令1,命令3,命令2>] [0170] ステップ5後:Acc/Sec1の残高の増加が再利用プロセスを開始する。 再利用の開始時に、メモリは次のようになる: Acc/Sec1 −400を含む −既に留保 −110に対して命令1 −失敗リスト<命令1,命令3,命令2>] [0171] 命令1(再利用リストの1番目)の再利用(及び決済)後: Acc/Sec1 −200を含む −既に留保 −0 −失敗リスト<命令3,命令2>] [0172] 命令3(再利用リスト内の新しい1番目)の再利用(及び決済)後: Acc/Sec1 −50を含む −既に留保 −0 −失敗リスト<命令2>] [0173] 命令2の再利用は失敗する(50の不足)。留保がない場合、メモリは変化しないままとなる。] [0174] 次に、ポジショニングエンジン154の動作280が図12を参照して以下に詳細に記載される。動作280は、ステップ282において、エンリッチ命令キュー166からのエンリッチ命令の読み出しで始まる。読み出された命令は次にステップ284においてタイムスタンプモジュール262によりタイムスタンプされる。1秒間に処理される命令の数を前提として、タイムスタンプは高い分解能を有し、典型的には時刻をマイクロ秒まで記録する。] 図12 [0175] タイムスタンプされたエンリッチ命令が新しいリファレンスデータ、即ちアップロードされたマスタレコードメモリテーブル186の対応するファイル30aに格納されていない特定のリソースアカウントファイル30に対する値を含む場合(ステップ286において決定される)、未知のリファレンスデータはアップロードされたマスタレコードメモリテーブル186に格納される。リファレンスデータが新しくない場合には、動作280は単にローカルバランス(残高)更新ステップ290に移動し、このステップは移動カルキュレータ及びローカルメモリストアアップデータ266で実行される。このステップにおいて、リファレンスデータはローカルメモリデータストア270内のアップロードされたマスタレコードメモリテーブル186から読み出され、命令に指定されている移動が読み出されたリファレンスデータに加えられ、リファレンスデータの結果値がアップロードされたマスタレコードメモリテーブル186の対応するファイル30aに書き戻される。] [0176] 次に、命令処理ロジック268が、ステップ292において、リファレンスデータの現在値を考察し、リソースアカウントファイル30及び集計リソース値32の更新された結果値がリソースデータの受け入れ可能値に関する所定の規則72に適合するどうかを決定する。適合しない場合には、3つのアクションが取られる。第1に、失敗の理由がステップ294において報告モジュール276を介して報告される。第2に、リソースデータの前の値がステップ296においてリストアされる。第3に、失敗した命令がステップ298において後の決済試行のために再利用リスト272に格納される。] [0177] 更新されたリファレンスデータが所定の規則72に適合する場合には、決済命令の成功実行がステップ300において報告モジュール276により報告される。この報告は、命令に関連するパーティに対する応答メッセージを生成し、アップデータ158にマスタデータベース24を更新するように命令する作用をなす。次に、この作用の影響がステップ302において清算され、即ちマスタアカウントデータに適用可能なリソースアカウント移動データが生成され、一群の残高更新メッセージが生成される。以下に示す実施例では、報告メッセージ及び残高更新メッセージの生成は2つのステップで記述される。] [0178] 最後に、再利用操作がステップ304において実行され、修正されたリファレンスデータが以前失敗した命令のいずれかを実行可能にするかどうかを確かめる。] [0179] 更新中として報告されるリファレンスデータのすべては、(プリローダの一つにより申請される同じデータの期限切れのものと交換して)再利用される命令を含む後続の決済命令を処理している間再使用するために、ポジショニングエンジン154のローカルメモリ(アップロードされたマスタレコードメモリテーブル186)に保持されることもちろんである。] [0180] ポジショニングエンジン154のローカルメモリ270のファイル30aに保持される更新されたリファレンスデータは単にクリアされるのではない。例えば1日の処理期間の終了時に、ポジショニングエンジン154は停止し、メモリの完全リセットを導く。このリセットは、ポジショニング実行中に大きな問題が起こったときにも生じる。すべての最終更新情報がマスタデータベース24に反映されること及びエンリッチ命令キュー166内のすべてのペンディング命令のクリアが複数のプリローダ152の再始動前に実行されること(このとき、マスタデータベース24はすべての残高の最終バージョンを反映する)を保証するために特定の再始動プロセスが導入されている。] [0181] 複数のプリローダ152及びポジショニングエンジンワーク154がどのように動作するかの非限定的な例が以下に与えられる。] [0182] 実施例: 命令1(ins 1)はプリローダインスタンス1(マスタデータコレクタ1)により処理される。この命令は(パーティAの)acc1と(パーティBの)acc2との間のリソースアカウントタイプsec1に対する決済命令「Sec1の10担保をSec2の500単位と交換する」である。 命令2(ins 2)はプリローダインスタンス2(マスタデータコレクタ2)により処理される。この命令は(パーティCの)acc 3と(パーティBの)acc 2との間のsec1に対する決済命令「Sec1の20担保をSec2の1050単位と交換する」である。] [0183] 2つの命令は並列に実行される。 インスタンス1により発生されるメッセージは次の通りである。 (命令のイメージ)+(関連するバランス(残高)のイメージ: acc1/sec1=1000, acc2/sec1=300, acc1/sec2=25000, acc2/sec2=30000…) インスタンス2により発生されるメッセージは次の通りである。 (命令のイメージ)+(関連するバランスのイメージ: acc3/sec1=3000, acc2/sec1=300, acc3/sec2=5000, acc2/sec2=30000…)] [0184] 2つのメッセージはポジショニングエンジンのエンリッチ命令キューに順に書き込まれる。 acc2/sec1及びacc2/sec2は同じ値で2度与えられることが明らかである。これらの値を最初に受信するときこれらの値(正確な値)を考察し、後から受信されるそれらの値は廃棄する(その代わりにメモリコピーを使用する)ことはポジショニングエンジン154の務めである。] [0185] ポジショニング結果は次の通りである。 インスタンス1から到来する命令を最初に処理する(順序は重要でない) 決済前のローカルメモリ186内のバランス: <エンプティ> 決済後のメモリ内のバランス: = 990 (1000-10) = 310 (300+10) =25500 (25000+500) =29500 (3000-500)] [0186] インスタンス2から到来する命令を処理する(順序は重要でない) 決済前のローカルメモリ186内のバランス(=前命令に対する決済後のバランス) = 990 (1000-10) = 310 (300+10) =25500 (25000+500) =29500 (3000-500) 決済後のメモリ内のバランス: = 990 (不変) = 330 (310+20:プリローダにより与えられた値300は廃棄される) =25500 (不変) =28450 (29500-1500:プリローダにより与えられた値30000は廃棄される) =2980 (3000-20) =6050 (5000+1050)] [0187] ファイナリティキュー168は本発明の重要な部分である。これは、与えられた命令の規則に関連する受諾可能性について行うポジショニングエンジン154の判断を命令の結果のリアルタイム報告及びマスタデータベース24の更新と分離する手段を表す。この分離により、ポジショニングエンジン154はその処理タスクを最小にでき、従ってこのように分離されない場合より大きなスループットをもたらす。] [0188] ポジショニングエンジン154の最終的状態(スタンプはどんなことがあっても決済命令が確認されたことを報告する)には、ポジショニングエンジンのそれぞれの更新をマスタデータベースに反映させることによって到達するのではなく、それぞれの更新をファイナリティキュー168において更新実行命令にログすることによって到達する。換言すれば、ファイナリティ命令レコード(更新実行命令)はディスパッチャ156の入力キューであるファイナリティキュー186に書き込まれる。同時に、もとの処理命令はファイナル、即ち実行されたとみなされる。命令に対するパーティへの通知を発生するとともにそれぞれの更新をアップデータ158の異なる入力キュー(マスタデータ分離キュー170)に分散させることがディスパッチャ156の務めである。主な目的は、同じ論理作業単位内に報告活動とデータベースバランス更新が混在するのを避けることにある。] [0189] ポジショニングエンジン154により発生される出力は一つの持続性メッセージ(潜在命令を完了させるために実行すべきすべてのマスタデータベース更新を含む)に限定されるため、それらの更新を分散させるとともに命令実行に関する所要の報告(例えばリアルタイム個別命令操作プロセス162へのリプライ)を発生する専用のプロセスがディスパッチャ156により与えられえる。入力に受信された一つのメッセージに対して、ディスパッチャ156は出力(更新されたリソースにつき1つ及び発生される報告につき1つ)を書き込む。全体スループット要件に対処するために、このディスパッチロジックは並列にランする。ディスパッチャ156はスケーラブルである(2つ以上のプログラムコピーを実行することによりスループットが大きくなる)。] [0190] ディスパッチャ156により発生される報告メッセージのフォーマットは簡単には構造化テキストメッセージである。しかし、このフォーマットは、必要に応じ外部フォーマット又はISOフォーマットに変更することができる。更に、ディスパッチャは、セッション中に起こったすべてのトランザクション及び関連する各エンティティに対するリソースアカウントファイル30及び集計リソース値32に与えたそれらの影響の結果を記載する処理セッション報告を発生するように構成される。] [0191] ディスパッチャ156は、どのマスタデータアップデータ190が更新の実行を命令されるべきかを決定しない。むしろ、これは以下に記載するようにルーティングフレームワーク175及びワークフローバランサ176に任される。] [0192] ルーティングフレームワーク175はワークフロー分散を助けるために設けられる。初期入力キュー164への入力及びディスパッチャプログラム188のマスタ分離キュー170への出力(アップデータ158へと向う)はルーティングフレームワーク175及びワークロードバランサ176を介して送られる。ディスパッチャプログラム188は命令をルーティングフレームワーク175に、その命令の正確な宛先(マスタ分離キュー170)を知らずに送る。ルーティングフレームワーク175の目的は、プラットフォーム上で同時に動作する複数の可能なキューのうちの一つを個別経路指定する命令を生成することにある。本例では、ルーティングフレームワークは必要に応じて複数の初期入力キュー164の一つ又はマスタデータ分離キュー170のうちの一つへの経路を指定する命令を生成する。ルーティングフレームワーク175は2つの技術的なフィールド、メッセージ名及びワークロード分散キー、を付加する。メッセージ名はメッセージに含まれる情報のタイプを記述し、ワークロード分散キーは命令IDに設定され、これにより2つの順次の実行試みが同じ報告順序で報告されることが保証され、例えばシーケンシング問題に起因する「決済された命令」に続いて「失敗した命令」を報告することが避けられる。] [0193] ルーティングフレームワーク175は、命令の経路指定をプロセス間で変更するために命令フローに新しいプロセスを付加する機能も有する。命令フローに新しい命令を付加して、プロセスからの命令の送出を抑圧し、必要に応じ命令を複製することもできる。メッセージ名及びワークロード分散キーを有する命令はワークロードバランサ176により以下に記載されるように操作される。] [0194] プラットフォーム150の動作において、ルーティングフレームワーク175の務めは、処理命令を送出する場合、誰に、どのフォーマットで及びどのインスタンス(並列処理のために)で送出するかを決定することにある。ルーティングフレームワーク175を使用して、一つの命令に対する報告は同じ命令に対する前報告の後に順序付けられるようにする。例えば、命令が最終的に受諾される前に数回失敗した場合に、該処理命令がサクセスフルに実行されたことの報告は同じ命令に対する失敗した決済報告メッセージの後に続かなければならない。また、各失敗した命令の報告も、命令送信パーティが失敗命令に正しく反応できるように順番に送出される。] [0195] 実施例:第1命令の処理試みは失敗する。理由⇒パーティAのリソースアカウントのレベルが命令をサポートするのに十分でない(パーティAは何らかのアクションを取り得る)。次に、第2命令の処理試みも失敗する。理由⇒パーティBのリソースアカウントのレベルが命令をサポートするのに十分でない(パーティBは何らかのアクションを取り得る)。これを報告する場合、パーティAのリソースアカウント失敗メッセージにパーティBのリソースアカウント失敗メッセージが後続することが重要である。ディスパッチャモジュールが並列にランしているとき、一つの命令に対するすべての報告をディスパッチャ156の同じインスタンスで送出すること(命令IDに基づくワークロード分散)がルーティングフレームワーク175の務めである。] [0196] ワークロードバランサ176は、命令名及び分散キー(図示せず)に基づいて命令の最終宛先を決定する。命令名及び分散キーは、処理プラットフォーム150により、併せて各命令を一意に記述するものとみなされる。メッセージ名は特定のマスタデータアップデータ190をフィードするターゲットマスタデータ分離キュー170を識別するために使用される(各マスタデータアップデータ190がどのように特定のタイプの更新に指示されるかについては後述する)。分散キーは特定のインスタンス(マスタデータ分離キュー170)を計算するのに使用される。ワークロードバランサ176は、同じ分散キーに対して、常に同じインスタンス(マスタデータ分離キュー170)を選択することを保証する(以下の簡単な実施例参照)。] [0197] 実施例: メッセージ名=SECURITY_BALANCE_UPDATE⇒担保残高更新 分散キー=担保id=13 並列にランする担保アップデータの総数= 3 選択されるインスタンス= 13 - (整数(13/3*3) + 1 = 13 - (4*3) + 1 = 13 - 12 + 1 = 2 ⇒担保id 13に対して更新を行う必要がある度に、インスタンス番号2が選択される。] [0198] マスタデータ分離キュー170の各々は、ルーティングフレームワーク175及びワークロードバランサ176により当該キュー170に明確に経路指定されたディスパッチャプログラム188からの命令を単に受信する。各マスタデータ分離キュー170は特定のマスタデータアップデータ190に関連し、このアップデータはマスタデータベース24の特定の部分24a,34b,24cにのみ作用する。] [0199] アップデータ158は、マスタデータベース24の一つの特定部分24a,24b,24cに、ポジショニングエンジン154によりファイナルとして宣言された更新命令を反映させるために設けられている。各マスタデータアップデータは固有のデータベース部分に独立に作用するため、他の更新プロセスにより発生される潜在的なロックにより影響されない。更に、各アップデータ190はそれが管理する一組のリファレンスデータを更新するだけであるため、更新命令のネッティング(相殺決算)を実行することができる。アップデータの各インスタンスは、(該インスタンスが経路指定されるアップデータを識別するために使用される)固有の一連のキーに基づいて働き、それらのキーがマスタデータベースの特定の部分に対して孤立しているかいないかはとはない。] [0200] アップデータ158を具体的にどのように実施するかについては2つの異なる実施例がある。一つの実施例では、更新命令(更新)はデルタ(差額)、即ちリソースアカウントファイルの値に対する変化により文書化される。別の実施例では、更新はリソースアカウントファイルの最終値で文書化される。これらの実施例はネッティングを実行するものとして以下に説明される。] [0201] 更新がデルタで文書化される場合、マスタデータアップデータ190により実行されるネッティングアルゴリズム(図示せず)は、所定のリソースアカウントファイルに対する各命令の移動を、当該リソースアカウントファイル30に対する一つの単一の更新を実行する前に合計するステップを含む。更新が最終値で文書化される場合、ネッティングはより高い更新タイムスタンプを有する値を維持し、更新メッセージの「〜の場合」節においてタイムスタンプ検証を加えるステップを含む。] [0202] 更に正確に言うと、最終値モデルでは、ネッティングプロセスはポジショニングエンジン154により実行された最終更新を維持しようとする。更新順序は保証されないので、ネッティングアルゴリズムは、12:45:03における最終値が既に受信された後に例えば12:45:01における最終値を受信する可能性がある。更新を実施するためには、12:45:03における最終値のみを考慮する必要がある。例えば12:45:06における最終値が既にデータベースに反映されている場合には、12:45:03における最終値は無視しなければならない。これは、マスタデータを更新する際にタイムスタンプを用いて以下に記載するように行うことができる。] [0203] EXECSQLUPDATE PP_SEC_BAL SETBLANCE_VALUE=入力に受信される最終値 バランスタイムスタンプ=最終値ポジショニングタイムスタンプ バランスID=更新要求からのバランスID及び バランスタイムスタンプ(DB内)<最終値ポジショニングタイムスタンプの場合] [0204] アップデータにより受信されるアップデータメッセージはファイナル(どこへでも供給可能)である。これは、これらのメッセージは、同じキーに対する2つの順次の更新命令が単一の物理的更新に変換されるようにグループ化することができることを意味する。] [0205] 最終値実施例及びデルタ値実施例がどのように動作するかを以下に例示する。 最終値に対する実施例 アップデータは次の入力を順に受信する。 バランス1 10000 2007-08-01-09.01.01.112335(マイクロ秒単位) バランス1 12500 2007-08-01-09.01.02.100475 バランス1 25000 2007-08-01-09.01.01.875221 バランス1 12500 2007-08-01-09.01.02.077054] [0206] マスタデータアップデータ190はすべての最新情報を順に読み出す。 第1の値に対して、アップデータはその値を維持する(最初に現在の論理作業単位においてバランスが参照される)。 第2の値に対して、アップデータはそのメモリ内の前値を上書きする(その要求は第1のものに比較して未来である)。 第3の値に対して、その要求は第2の値より前に発生されたため、アップデータはその値を廃棄する。 第4の値に対して、その要求も第2の値より前に発生されたため、アップデータはその値を廃棄する。] [0207] コミットタイム(コミット周波数)で、物理的更新が発生する: EXECSQLUPDATESETバランス値=12500 タイムスタンプ=2007-08-01-09.01.02.100475] [0208] バランスid=バランス1及びタイムスタンプ<2007-08-01-09.01.02.100475の場合 データベース内のイメージが申請されたものに比較して既に未来である場合、タイムスタンプ条件が更新要求を中止する。] [0209] デルタに対する実施例 マスタデータアップデータ190は次の入力を順に受信する。 バランス1 10000 2007-08-01-09.01.01.112335(マイクロ秒単位) バランス1 12500 2007-08-01-09.01.02.100475 バランス1 25000 2007-08-01-09.01.01.875221 バランス1 12500 2007-08-01-09.01.02.077054] [0210] マスタデータアップデータ190はすべての最新情報を順に読み出す。 第1の値に対して、アップデータはその値を維持する(最初に現在の論理作業単位においてバランスが参照される)。 第2の値に対して、アップデータはデルタ10000+12500=22500の加算を行う。 第3の値に対して、アップデータはデルタ22500+25000=47500の加算を行う。 第4の値に対して、アップデータはデルタ47500+12500=60000の加算を行う。] [0211] コミットタイム(コミット周波数)で、物理的な更新が発生する: EXECSQLUPDATESETバランス値=バランス値+60000 バランスid=バランス1の場合] [0212] キューがペーシングモジュール174を介して通常空にされることは、プラットフォームを通る命令のフローに実施される唯一の制御ではない。リアルタイム処理中、デリミタフレームワーク178は、処理セッションの終了時にディスパッチャ156内の活動の報告を開始するために処理セッションの終了前に実行されたすべての更新がマスタデータベース24に正しく反映されるようにする。] [0213] ファイナリティキュー168への更新実効命令の書き込みは、マスタデータベースの更新がまだ実行されていない場合でも、プラットフォーム150による命令の最終実行とみなすことができる。しかし、技術的観点からすると、依然として、更新実行命令はマスタデータベースリソースアカウント30の値に依存する前にマスタデータベース24において実際に実行されるようにする必要がある。] [0214] この目標制約を達成するために、デリミタフレームワーク178は要求/応答メッセージをファイナリティキューのトップに書き込む基本的な機能を提供する。これは、応答が受信されるとき、ファイナリティキューに先に書き込まれたすべての命令が実行されたことを意味する。] [0215] プラットフォーム150における命令処理フローは順に実行される一連のプロセスからなる。特に、マスタデータ分離キュー170は更新実行命令を、それらがファイナリティキューを通過した後にのみ操作する。従って、ファイナリティキューから応答が受信されると同時に、新しい要求/応答メッセージが次のキュー、即ちマスタデータ分離キュー170に順に送られる。各キューはFIFOシーケンス動作する。]
权利要求:
請求項1 極めて多数の処理命令をリアルタイムに処理及び操作するシステムであって、各処理命令は2つの異なるエンティティに関するリソースアカウントデータファイル及びこれらのファイル間で交換されるリソースの量及びタイプを指定するものであり、該システムは、複数のプリローダを備え、各プリローダは前記処理命令に関連するリファレンスデータを取得するように構成され、前記リファレンスデータは指定されたリソースアカウントデータファイルの各々の現在値を示し、前記複数のプリローダは並列に動作して複数のそれぞれの受信処理命令に対する前記リファレンスデータをマスタデータベースから読み出すように構成され、更に複数の前記処理命令をそれらのそれぞれのプリロードされたリファレンスデータと一緒にキューイングするエンリッチ命令キューと、受信した前記リファレンスデータを用いて、各受信処理命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかをシーケンシャルに決定し、各実行可能な処理命令に対して更新コマンドを発生するように構成された実行エンジンと、前記実行エンジンからの前記更新コマンドに応答して、前記マスタデータベースを各実行可能な命令の結果で更新する複数のアップデータと、を備え、前記複数のアップデータの動作が前記実行エンジンの動作から分離されている、システム。 請求項2 複数の異なるソースからリアルタイム命令及びバッチ命令を受信し、これらの命令を前記複数のプリローダへの入力のためにキューイングするように構成された初期入力キューを更に備える、請求項1記載のシステム。 請求項3 前記初期入力キューは複数の初期入力キューを備え、前記複数の初期入力キューの一つが前記複数のプリローダの対応する一つへの専用の入力を提供する、請求項2記載のシステム。 請求項4 前記初期入力キュー叉は前記複数の初期入力キューの各々は入力する各命令に優先順位を指定するように構成されている、請求項2又は3記載のシステム。 請求項5 前記実行エンジンに格納された現在状態テーブルを更に備え、前記現在状態テーブルは、更新されたリソースアカウントファイルの各々の更新されたリアルタイム値の表現が得られるように、前記リソースアカウントファイルに対して実行された命令の結果で更新されるように構成され、前記実行エンジンは、後続の命令のシーケンシャル処理のために、特定のリソースアカウントファイルに対して、前記現在状態テーブル内の情報を前記プリローダからのリファレンス情報に優先して使用するように構成されている、請求項1−4のいずれかに記載のシステム。 請求項6 各プリローダはマスタデータコレクタを備え、各マスタデータコレクタは、前記マスタデータベースから、前記命令に指定されるリソースアカウントファイルの値及び集計リソース値を読み出し、前記マスタデータベースから読み出されたデータを含むエンリッチ処理命令を編集し出力するように構成されている、請求項1−5のいずれかに記載のシステム。 請求項7 前記実行エンジンは前記現在状態テーブルを格納する高速ローカルデータメモリを備える、請求項1−6のいずれかに記載のシステム。 請求項8 前記実行エンジンは、格納されている一群の所定の規則を参照することによって現在命令を関連するリソースアカウントファイルの現在値に基づいて実行できるかどうかを決定するように構成されている、請求項1−7のいずれかに記載のシステム。 請求項9 前記実行エンジンは、前記処理命令の一つの受信時刻を決定し、タイプスタンプを生成し、これを前記処理命令に付与するように構成されたタイムスタンプモジュールを備える、請求項1−8のいずれかに記載のシステム。 請求項10 前記実行エンジンは、失敗した処理命令のリストを高速のローカルデータストアに格納し、前記失敗した処理命令により特定されるリソースアカウントファイルにおいて更新が起こった後に、前記失敗した処理命令が再実行のために提示される場合に再利用プロシージャを実行する再利用モジュールを備える、請求項1−9のいずれかに記載のシステム。 請求項11 前記再利用モジュールは、前記失敗命令をそれらの優先順位の順に格納し、再利用プロシージャの間最高優先順位の命令を再実行のために最初に提示するように構成されている、請求項10記載のシステム。 請求項12 前記再利用モジュールは、前記リスト内の命令に関するリソースアカウントファイルの現在値を留保し、この留保された量を再利用プロシージャ中に命令の要件をかなえるために利用するように構成されている、請求項10又は11記載のシステム。 請求項13 前記再利用モジュールは、失敗処理命令を再実行のために所定の最大回数にわたり提示し、この失敗命令が依然として実行されなかった場合に、この失敗命令をキャンセルするように構成されている、請求項10又は12記載のシステム。 請求項14 前記実行エンジンは、前記受信命令の一つの実行の結果を報告する報告モジュールを備え、前記報告モジュールは、実行できると決定された各命令に対して更新コマンドを出力し、各失敗命令に対して通知命令を出力するように構成されている、請求項1−13のいずれかに記載のシステム。 請求項15 前記報告モジュールは、コミットイベントが発生するまで複数の更新コマンドを一時的にストアし、コミットイベントの発生時に前記ストアされている複数の更新コマンドを出力するように構成され、前記コミットイベントは前記実行エンジンによる一つの物理的作業単位の終了を表す、請求項14記載のシステム。 請求項16 前記報告モジュールからの前記更新コマンド及び前記通知命令を受信するように構成されたファイナリティキューを更に備える、請求項1−15のいずれかに記載のシステム。 請求項17 各アップデータは並列に動作する複数の更新インスタンスを備え、各インスタンスは前記マスタデータベースの特定の部分で動作する、請求項1−16のいずれかに記載のシステム。 請求項18 各更新インスタンスに対して分離入力キューを更に備え、各分離入力キューは対応する更新インスタンスにより更新される前記マスタデータベースの特定の部分に関係する複数の更新コマンドを受信するように構成されている、請求項17記載のシステム。 請求項19 各分離入力キューは、更新コマンドが同じリファレンスアカウントファイルに関係する場合に、更新コマンドのネッティングを実行するように構成されている、請求項18記載のシステム。 請求項20 各更新コマンドの特定の分離入力キューへの経路を決定し、実効命令の失敗又は成功を記述する、前記異なるエンティティのための報告メッセージを生成するように構成されたディスパッチャを更に備える、請求項18又は19記載のシステム。 請求項21 ルーティングフレームワークを更に備え、前記ルーティングフレームワークは、命令を同時に動作する複数の初期入力キュー又は分離入力キューに分配するように構成されている、請求項3に従属する請求項18又は20記載のシステム。 請求項22 前記ルーティングフレームワークは、命令が関連する情報のタイプを記述する命令名及び命令を特定する一意のキーを提供するワークロードバランサキーを命令に指定するように構成されている、請求項21記載のシステム。 請求項23 前記ルーティングフレームワークは、当該ルーティングフレームワークと共同して、受信した前記命令名及びワークロードバランサキーを用いて、前記複数の初期入力キュー又は分離入力キューのうちの一つを選択するように構成されているワークロードバランサを備える、請求項22記載のシステム。 請求項24 前記ワークロードバランサは、特定のリソースアカウントデータファイルに関連するすべての命令が常に前記複数のキューのうちの同じ一つに経路指定されるようにするために、所定のワークロードバランサキーを同じ特定の宛先にリンクするように構成されている、請求項23記載のシステム。 請求項25 所定の時刻における処理セッションの終了に応答して、メッセージを前記実行エンジンの出力に設けられたキューの入力に送り、その応答を待ち、更なるメッセージを前記複数のアップデータの一つの入力キューに送り、その応答、即ち前記処理セッションの終了前に実行された処理命令のすべての結果による前記マスタデータベースの更新を示すシーケンシャル応答の受信を待つように構成されたデリミタフレームワークを更に備える、請求項1−24のいずれかに記載のシステム。 請求項26 前記デリミタフレームワークは、更に、メッセージを前記ディスパッチャモジュールの入力キューに送り、前記処理セッションの終了前に実行された処理命令に対する報告メッセージがすべて送信されたことを確認するためにそれぞれのフィードバックを待つように構成されている、請求項25記載のシステム。 請求項27 前記実行エンジンの処理命令のスループットを測定し、処理命令のローディング速度を前記実行エンジンのスループットより低くするために任意のキューに待ち状態を与えるペーシングモジュールを更に備える、請求項1−26のいずれかに記載のシステム。
类似技术:
公开号 | 公开日 | 专利标题 US20200334645A1|2020-10-22|Resource transfer system US20170206240A1|2017-07-20|Multi-database log with multi-item transaction support CN105144161B|2019-05-10|针对复制写入的基于令牌的准入控制 US9002805B1|2015-04-07|Conditional storage object deletion Levandoski et al.2011|Deuteronomy: Transaction support for cloud data CN101770515B|2012-01-11|一种基于数据块比较的数据更新方法 US6233585B1|2001-05-15|Isolation levels and compensating transactions in an information system US20190034465A1|2019-01-31|Blockchain logging of data from multiple systems KR101863398B1|2018-05-31|다중-서버 예약 시스템 상의 동기화 메커니즘 시스템 및 방법 Ardekani et al.2013|Non-monotonic snapshot isolation: Scalable and strong consistency for geo-replicated transactional systems US6052684A|2000-04-18|System and method for performing consistent workflow process execution in a workflow management system EP2454666B1|2014-11-12|Fault tolerant batch processing US20150172412A1|2015-06-18|Managing dependencies between operations in a distributed system US7386577B2|2008-06-10|Dynamic determination of transaction boundaries in workflow systems De Prisco et al.2000|Revisiting the Paxos algorithm US7330860B2|2008-02-12|Fault tolerant mechanism to handle initial load of replicated object in live system US6085200A|2000-07-04|System and method for arranging database restoration data for efficient data recovery in transaction processing systems KR101126979B1|2012-03-26|분산형 고장 허용 및 고가용성 컴퓨팅 시스템 US6012094A|2000-01-04|Method of stratified transaction processing US7983971B1|2011-07-19|Accounting system and method US8375095B2|2013-02-12|Out of order durable message processing JP2015519639A|2015-07-09|スケーラブルな構造化データ配布のためのシステム及び方法 CA2413615C|2008-05-27|Conflict resolution for collaborative work system US7356532B2|2008-04-08|Systems and methods for maintaining transactional persistence CN103782574B|2017-05-10|用于数据库事务的幂等性
同族专利:
公开号 | 公开日 US20110004788A1|2011-01-06| CN102016842B|2014-07-30| EP2096564A1|2009-09-02| AU2009219899A1|2009-09-03| TW200943182A|2009-10-16| WO2009106901A1|2009-09-03| US8612299B2|2013-12-17| CA2716640A1|2009-09-03| AU2009219899B2|2014-05-08| CN102016842A|2011-04-13| EP2096564B1|2018-08-08| RU2010136683A|2012-03-10| TWI503745B|2015-10-11| KR20110000737A|2011-01-05| RU2465634C2|2012-10-27| US20180365283A1|2018-12-20| KR101616967B1|2016-05-12| BRPI0906031A2|2015-06-30| MY155436A|2015-10-15| CA2716640C|2015-11-24| US10025809B2|2018-07-17| US20140149342A1|2014-05-29| JP5603780B2|2014-10-08| WO2009106901A8|2009-11-05|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题 JPH0342741A|1989-07-11|1991-02-22|Nippon Denki Joho Service Kk|Updating system for distributed data base in inter-host communication| JPH03168847A|1989-11-29|1991-07-22|Hitachi Ltd|High-speed data base control system| JPH08328933A|1995-05-30|1996-12-13|Nec Corp|並列処理システムのファイルアクセス制御方式| JP2006338197A|2005-05-31|2006-12-14|Fujitsu Ltd|トランザクション制御プログラム、トランザクション制御方法及びトランザクション処理システム|JP2016144169A|2015-02-05|2016-08-08|株式会社日立製作所|通信システム、キュー管理サーバ、及び、通信方法|CA1337132C|1988-07-15|1995-09-26|Robert Filepp|Reception system for an interactive computer network and method of operation| CA2145363C|1994-03-24|1999-07-13|Anthony Mark Jones|Ram interface| US7117165B1|1997-04-28|2006-10-03|Ariba, Inc.|Operating resource management system| US7216348B1|1999-01-05|2007-05-08|Net2Phone, Inc.|Method and apparatus for dynamically balancing call flow workloads in a telecommunications system| US6463509B1|1999-01-26|2002-10-08|Motive Power, Inc.|Preloading data in a cache memory according to user-specified preload criteria| US7630986B1|1999-10-27|2009-12-08|Pinpoint, Incorporated|Secure data interchange| US6714978B1|1999-12-04|2004-03-30|Worldcom, Inc.|Method and system for processing records in a communications network| CN1209719C|2000-11-13|2005-07-06|国际商业机器公司|用于将服务器上的业务提供给用户设备的方法和系统| NZ536004A|2002-04-19|2006-10-27|Radixs Pte Ltd|System and method for use of multiple applications in a mobile computing environment| FR2890267B1|2005-08-26|2007-10-05|Viaccess Sa|Procede d'etablissement d'une cle de session et unites pour la mise en oeuvre du procede| US7983971B1|2006-01-26|2011-07-19|Fannie Mae|Accounting system and method| TW200809529A|2006-02-16|2008-02-16|Technology Properties Ltd|Computer system with increased operating efficiency|KR101775554B1|2010-02-18|2017-09-07|삼성전자주식회사|동적 기계어 코드 생성시 명령어 및 데이터의 배치 방법 및 장치| US20130290486A1|2011-02-28|2013-10-31|Mitsubishi Electric Corporation|Communication device| US8688661B2|2012-06-15|2014-04-01|International Business Machines Corporation|Transactional processing| US9317460B2|2012-06-15|2016-04-19|International Business Machines Corporation|Program event recording within a transactional environment| US9772854B2|2012-06-15|2017-09-26|International Business Machines Corporation|Selectively controlling instruction execution in transactional processing| US9448796B2|2012-06-15|2016-09-20|International Business Machines Corporation|Restricted instructions in transactional execution| US20130339680A1|2012-06-15|2013-12-19|International Business Machines Corporation|Nontransactional store instruction| US9436477B2|2012-06-15|2016-09-06|International Business Machines Corporation|Transaction abort instruction| US10437602B2|2012-06-15|2019-10-08|International Business Machines Corporation|Program interruption filtering in transactional execution| US9442737B2|2012-06-15|2016-09-13|International Business Machines Corporation|Restricting processing within a processor to facilitate transaction completion| US9367323B2|2012-06-15|2016-06-14|International Business Machines Corporation|Processor assist facility| US9740549B2|2012-06-15|2017-08-22|International Business Machines Corporation|Facilitating transaction completion subsequent to repeated aborts of the transaction| US9336046B2|2012-06-15|2016-05-10|International Business Machines Corporation|Transaction abort processing| US9384004B2|2012-06-15|2016-07-05|International Business Machines Corporation|Randomized testing within transactional execution| US9361115B2|2012-06-15|2016-06-07|International Business Machines Corporation|Saving/restoring selected registers in transactional processing| US8682877B2|2012-06-15|2014-03-25|International Business Machines Corporation|Constrained transaction execution| US9348642B2|2012-06-15|2016-05-24|International Business Machines Corporation|Transaction begin/end instructions| CN103577251A|2012-07-20|2014-02-12|中兴通讯股份有限公司|基于事件的互联网计算处理系统及方法| US9207964B1|2012-11-15|2015-12-08|Google Inc.|Distributed batch matching of videos with dynamic resource allocation based on global score and prioritized scheduling score in a heterogeneous computing environment| SG10201809241XA|2013-06-27|2018-11-29|Euroclear Sa/Nv|Asset inventory system| CN104375993B|2013-08-12|2018-02-02|阿里巴巴集团控股有限公司|一种数据处理的方法及装置| KR20150033454A|2013-09-24|2015-04-01|주식회사 엘지씨엔에스|빅데이터 처리 장치 관리 방법 및 이를 수행하는 관리 시스템| CN110781244A|2014-12-03|2020-02-11|阿里巴巴集团控股有限公司|用于对数据库的并发操作进行控制的方法及装置| CN104915886B|2015-01-04|2018-06-26|杭州时代银通软件股份有限公司|一种外汇牌价处理系统及方法| CN105828309B|2015-01-05|2019-07-02|中国移动通信集团广西有限公司|一种话单处理方法、设备及系统| US10248337B2|2015-12-08|2019-04-02|Ultrata, Llc|Object memory interfaces across shared links| US9971542B2|2015-06-09|2018-05-15|Ultrata, Llc|Infinite memory fabric streams and APIs| US10698628B2|2015-06-09|2020-06-30|Ultrata, Llc|Infinite memory fabric hardware implementation with memory| CA2974360A1|2015-01-20|2016-07-28|Ultrata, Llc|Object memory data flow instruction execution| US9965185B2|2015-01-20|2018-05-08|Ultrata, Llc|Utilization of a distributed index to provide object memory fabric coherency| US10241676B2|2015-12-08|2019-03-26|Ultrata, Llc|Memory fabric software implementation| US9886210B2|2015-06-09|2018-02-06|Ultrata, Llc|Infinite memory fabric hardware implementation with router| CN104657462B|2015-02-10|2017-12-22|北京宇航系统工程研究所|一种海量测量数据准实时入库方法| RU2609089C2|2015-02-24|2017-01-30|Общество С Ограниченной Ответственностью "Яндекс"|Система и способ выполнения очереди запросов в отношении цифровых объектов| CN104954450B|2015-05-29|2018-07-24|北京奇虎科技有限公司|一种文件处理方法和装置| EP3387548A4|2015-12-08|2019-08-14|Ultrata LLC|Memory fabric operations and coherency using fault tolerant objects| CN105763595A|2015-12-23|2016-07-13|杭州赫智电子科技有限公司|一种提高数据处理效率的方法及服务器| CN106201992A|2016-07-14|2016-12-07|贵阳朗玛信息技术股份有限公司|一种大数据实时运算方法及装置| US10510108B2|2016-09-28|2019-12-17|Paypal, Inc.|Method, medium, and system for managing queueing and de-queueing operations of transaction queues| US10438275B2|2016-09-28|2019-10-08|Paypal, Inc.|Method, medium, and system for managing de-queueing operations of transaction queues| US10642801B2|2017-08-29|2020-05-05|Bank Of America Corporation|System for determining the impact to databases, tables and views by batch processing| US10503438B1|2018-08-24|2019-12-10|Micron Technology, Inc.|Memory sub-system supporting non-deterministic commands|
法律状态:
2012-02-22| A621| Written request for application examination|Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120221 | 2013-09-26| A977| Report on retrieval|Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130926 | 2013-10-02| A131| Notification of reasons for refusal|Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20131001 | 2013-12-28| A601| Written request for extension of time|Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20131227 | 2014-01-14| A602| Written permission of extension of time|Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20140110 | 2014-03-01| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140228 | 2014-07-31| TRDD| Decision of grant or rejection written| 2014-08-06| A01| Written decision to grant a patent or to grant a registration (utility model)|Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140805 | 2014-08-28| A61| First payment of annual fees (during grant procedure)|Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140822 | 2014-08-29| R150| Certificate of patent or registration of utility model|Ref document number: 5603780 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 | 2017-06-06| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 | 2018-09-04| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 | 2019-08-29| LAPS| Cancellation because of no payment of annual fees|
优先权:
[返回顶部]
申请号 | 申请日 | 专利标题 相关专利
Sulfonates, polymers, resist compositions and patterning process
Washing machine
Washing machine
Device for fixture finishing and tension adjusting of membrane
Structure for Equipping Band in a Plane Cathode Ray Tube
Process for preparation of 7 alpha-carboxyl 9, 11-epoxy steroids and intermediates useful therein an
国家/地区
|